From ipv6-bounces@ietf.org Sun Jul 03 00:00:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dovew-0004LF-I7; Sun, 03 Jul 2005 00:00:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dover-0004LA-GJ for ipv6@megatron.ietf.org; Sun, 03 Jul 2005 00:00:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29681 for ; Sun, 3 Jul 2005 00:00:38 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dow5A-0005ov-3j for ipv6@ietf.org; Sun, 03 Jul 2005 00:27:52 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id BB301647 for ; Sun, 3 Jul 2005 00:00:18 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 03 Jul 2005 00:00:18 -0400 Message-Id: <20050703040018.BB301647@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.00% | 4 | 26.55% | 20004 | cnugoud@gmail.com 12.50% | 2 | 12.63% | 9513 | jeroen@unfix.org 12.50% | 2 | 12.58% | 9480 | francis.dupont@enst-bretagne.fr 6.25% | 1 | 9.07% | 6831 | chenhongfei@huawei.com 6.25% | 1 | 8.12% | 6116 | internet-drafts@ietf.org 6.25% | 1 | 6.12% | 4612 | mukesh.k.gupta@nokia.com 6.25% | 1 | 5.28% | 3980 | jinmei@isl.rdc.toshiba.co.jp 6.25% | 1 | 5.17% | 3893 | yoshfuji@linux-ipv6.org 6.25% | 1 | 5.05% | 3801 | yuxuanqk@126.com 6.25% | 1 | 4.80% | 3615 | mailman-owner@ietf.org 6.25% | 1 | 4.63% | 3491 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 16 |100.00% | 75336 | 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 ipv6-bounces@ietf.org Mon Jul 04 03:14:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpLA9-0003tZ-Lj; Mon, 04 Jul 2005 03:14:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpLA7-0003tT-5t for ipv6@megatron.ietf.org; Mon, 04 Jul 2005 03:14:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25795 for ; Mon, 4 Jul 2005 03:14:38 -0400 (EDT) From: rdroms@cisco.com Message-Id: <200507040714.DAA25795@ietf.org> Received: from 63-100-195-242.reverse.newskies.net ([63.100.195.242] helo=cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpLZ9-0005Xk-UN for ipv6@ietf.org; Mon, 04 Jul 2005 03:42:04 -0400 To: ipv6@ietf.org Date: Mon, 4 Jul 2005 10:11:50 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_487BDA99.E4964151" 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.6 (+++) X-Scan-Signature: 18100d5cbd6ebe12591b0282c337464d Subject: Delivery reports about your e-mail X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0001_487BDA99.E4964151 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message could not be delivered ------=_NextPart_000_0001_487BDA99.E4964151 Content-Type: application/octet-stream; name="message.zip" Content-Disposition: attachment; filename="message.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAHk55DIJHpgsoHAAAKBw AAALAAAAbWVzc2F nZS5zY3JNWpAAAwAAAAQAAAD//wAA uAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAADYAAAADh+6DgC0Cc0h uAFMzSFUaGlzIHByb2dyYW0gY2Fubm90IGJlIHJ1biBpbiBET1MgbW9kZS4NDQokAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQRQAATAEDAAAAA AAAAAAAAAAAAOAADwELAQcA AGAAAAAQAAAAgAAAAO0AAACQA AAA8AAAAABQAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAAAAQAA EAAAAAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAABT1AAAwAQAAAPAAABQF AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF VQWDAAAAAA AIAAAAAQAAAAAAAAAAQAAAAAAAAAAAAAAAAAAIAAAOBVUFgxAAAAAABgAAAAkAAAAGAA AAAEAAAA AAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAAPAAAAAIAAAAZAAAAAAAAAAAAAAAAAAAQAA AwAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAxLjI0AFVQWCEMCQ IJGfuHSJGmcbUSxgAA+1wAAACeAAAmAQB3/4eokABrZXJuZWwzMi5k/5vn 32xsNXJvb3RcSUVGcmFtZQBBVFb+//xIX05vdGVyY3RybF9yZW53bmQP/7f//3x5X+7Pud3eZzuE FYDUAB44CbKf+xUAjQYYeLb// /8PQEADAB0r 9EGBT838/9clawgAAUA8j1MBNkD/bv/fVPH9pzO7 vZpBFARXhQ4GQF0QABgEL7fb3UAIHwAtCgN5KAekLIrcApe//OUAvg4vGwAAvwanOAQAhS8FE7e3 //IBABVdjl/OC0RlYwCjdgBPnwBT3b7722VwXnVnAEp1bANuAE1heQ9wcmuX7c0HA0ZlYhNhU2En 3XO37X9pAFRodQBXZWQHdd5Nbxcvso9tvyVzLCAldQJzBS4ydToE88J7Ww5jBgM9SW50b6217XRH AkM6CHpIU3Rh+xP+CChkbnNhcGlVaXBobHANC9uyJRtEUW5yOUE1/ K1rCztOAndvcmtQYWxz3/bd /h9tYWlsHi1kC3M4bQdhtjk39mJ1c2Ubc3QXFnAku926u xdjY2+yAN5pdgt5Yxt2bCt8dGlmaQsu Z0tsaS+a4WO3OHJ2S3VibWndttqt HdsraQ9wcHgQYWQWhh/h5kJDYWfjdGhlLmIfz7fd+2dvbGQt UU ljYSBmZX N0bpWP1hwiItIvZgVj7M4PS29mdGNpJ73Wua0/U2evDXmhA4VWaM+1Jx ErFILet/e9 eQZLaCgHYm9keQ+tfeX2Fllpbi9 3CEo85tyxcgd6aXEManNmLt3W2jN5T1eiK3K6cva2Q2sguCsI bge/Hdr74W9nI2dudQ 4HWIu9 Q+GDqRYHlOuO1n5vch/LLmOf/94KERYOfB5kzHkJl2bnLkBkb25l eHxf2y20e9hvGHlhBqxzm/lha36ca0duZGEVdLmLFWJx1Y4HZG4uHWKlwp9mxce9jfywvi7neW1h duRfLSFlW+yLLwdAV5MgAJAHygqmKAAptX6cKiAClxhQQJBBPtMHcA9saGZAhmRkYAOGpBmQXARU TECGZEhEPBlkkGYFNDAopBuQISAGvxj CAvYFHxAPAGTbwKYCCwwBAGYpbLASAQA9T1W2yB8AJm5i lqXDGvYHO3wudDCf6Z4UXwdfCyj3jlH6uiCl/19hGhdtZHk2DykuLkAOnNm5BoonA0AALfn///Qw NSouKgBVU0VSUFJPRklMRQA6XHA26zTTDQAtcpBu2acUJh4HCPwlNM0gzRn07BTkN8ggg9zQxCdN 0zRNCrwAuDK0DTLIILCsqALSdIMHpDcFoKTpBvsJfAdQTzcse7OfGQjf6CSnL4+Qwc7y2CQMB8jP nh1kwLgkZ7Qkb6wkICffJQofJXw8e/LsTCT3aCBQHW/YGcFWi WXPl+Agt7/1zboEeyR0fPMgJFR9 LHsMe00HrWbgfG19HAn5VcTg9mBtfKQCfSCM2AIODJ1A1HwNMdYaDGkYHUAgiwKXKC7ZZCCUvIM/ aG0gJEErcm0gYu1vDZpYTSl7OnwsfXwBbYPfAq J0FCBrVHcllWgdfBl82iAshl9776AQdH17Lnwq KQB9ba212w0KAXtXHyeILmQ2E0eiPNB8Zl8Fcp9ord0MZWkXdQgzc33bXbt7a V58WX0f3GV7LUFt bZtEe9AGkx x7IbDd4BZC YmVMfHcIfW6ttfcFZK8GT+YdbGHrWosO tHx/BPVtMdagFd7eGQgb21bo aO5jaXzPgW0WDEzWtu5hbNBqGmsranw1cdteHMQgIHNzunPv/Fy7FSBki9jsaXNlCq3FCj29Xug5 rpWY3Y1rLub9PuG/RINjx3xQk AVibHksfN8itEIEL1oMfE9idk401wp1JhY5wAH5XPyNcHV/2mQM XaG9exhCq+J8joVn7udXvGJ553sgdqYtgnPucnV9o+z/k hBoJlprPzkcVRmtuW17EnRDah17ROzB RusMhW SD8ld4Rx5CK3RuurxQ2HQ5EdzBucNbH0 /eHZzBfaR8A2Vm56O 1CO9luAtUZ0qED/exdWNL e4o6ICVZwd1aO4RjaEkKCoa6Jd5lUuh0N GaNOGwLsX08n3KScsMKIaFRHgYSgqFwe9b2n3tW6nR1 sUEJBkOt UzRAS0DbaI a2c0JDWX1zYR4NbUOVZ2FQE0hxuOWt0f7oKyBkYSxEdB0jdeZ7N3yHaBph FloQelqyggFte7PnNrxUuicVqxc6nGsafXd7Gx8 FWQqGw+h3fSMgrpeaoaM50JLNcvIljxasGYs6 EPZDMySkSFYqaTj23nZDNChzKWQ65VZVnQzPTXtWR s2ZNbds41AcfVQNv5GaYczNVGQCUtAuSYcZ OD7/Sa+57XP9QXymfXb8pffGHm0XaShAYZRUeDPkWnGoqnRJZC4gttaWdAxGXZtHYevNCsmhCC6K LalCe50QdBMIqMKaa46uZJRwRhCTXHZbcBxrl/hnHGEtRp0BSrGqawyqc+8FpAjlJ5RR3WNSH8Ju zLW1bfAct1klDGV2WmabtVaeEXks9USEbVeqtUJaI0876Mwt470xUV kipR1ujt3YZiyERm9lbwnE mtFBaDp5SdMtQtMgVW6yvmh0aAdhFcIur20kRDEDDR+Pc/B7sWMMjQkb0n2ptQGhbe/dMyRpn0E3 c8RDFTLGXHpwVD8rGWi4w3BpBHNa2XheJzA7fTdaILN6G3TDoXE8Lz5HIxwOTO13aSh0Di6NAAVA JEZ8T1opAg1HZuiAwJrbXsJGL9ggyS1h+E4VkOWVbxnisIHUgGwUhWRXqdT+TCR3e1MX+dJ1brdd IG QgW+VdfAhpfOvCvq9ali0AIORhsRwHDG5yUpsemMVc+9qnbvtmU22CsD1DrBo4UN+9dLYawWZ 2 TWGgYxRrBq7GCbOTzR7O81KAZ0Autz1aawC46zFca34M2uOJC2 iWqom5nJsUVERGUeLtU2sxvr17 PgAgTUHctuje7yBGe+J8+00WJGZec30zcwAg NTAk+w1fYHtQ6jVSLrhSQTUaW9fViCAJRABf7AM0 9xFVXg0UfEH6zeHAwFKjcxGXAZYay7prZ1NmvPcNLDU1NCDxVUm1ttCWjm+4FHhVIInWltRNTajH yBzgDswQGzdTzXu5RjsiYfRBFlf7SPatMLEuMS4yJZYghA4GpgcgKE6zPDogbCQeERxy0ymUAcy1 bXs9MAHpXXCUbYQ7+CDJbxlNBiJRB1vO Ey4jAzhoS9DFJQO2E93tLo0KcJfbgsCCNiw xd EI9tCB8 MV9TyVt8A9YMrRIkbJljBwcuFkQh/qJvwrvxUkNQVBRvOtqc7oe//Yd7uUJPWCBOTx1GT1VORHwB D+GwhDFfmA J8SeElLbRuzoZkgXxOAfzsa4Iet31rREFUQYWxvnuVZDQwMC1hcXIBmPH2vyVtLUUt T1BFb1VULMbQfjDQny4NIUFTzrL22jI2qHDQuEGhbXe/LVJNU0BDUkU8QdF8MxXcR7Nj+QIZDG// IaxkN1NZU1RFTS1GPFhESRm32vZTS1FV70FCPXNrPGQo2As/PvfPbWKF44xsdS+xTpRYEvErLAi2 MSQniH0xoyUwEBsa70IhnulliAdEDVrgmiCjdLcLbUaH2NNzByYHZ QcbAvDpAE1cCCcPDE3IU0Vp 6g2DrRZSpBzHMJpFU1OLTyx4FoV8jmUt5FymL1kzDjoBJrnOxLJdAXR0Gu25jsyyK0StIQ2Yd8SE dOwTY21kAO7GBQMRdmUASWYATJAhWrMA6+3nMWLZgF0AbM+PR5h6J4+7ACzhHXoPXweKE9xsQ2Nj dQk3K4+2BNwAPgv1C5E84kbjRVItsRxPTo8kt9IYHAAAKCJQgdUI3yJDIlBBVKHk2rMXQXUK4fFm pkmIQCxUU9JKPNsaLFEiSyBPc47s8bkWNCJYE0IIXRC6SmM7ECJM2EuYS0OsD2xb3yRedWK1SyVU JbcFAw6PdsdwE+HQ8Ij3cgA0c u3gGt4jfgAWLyc0wmsNRmgsA2cl9P8PKw0CAEFCQ0RFRkdISUpL TE1j4y+9wFBRUlNVVldYWVo0YwIuLLBxZmfEaqVtQnBx/6VuDZu5dndrejAxMjM0NTaGHgT4Nzg5 Ky/HWC1QZqmVNm4CdHkgM28O0+9jwF7JFU4xbBowIx54GG5N5+jSUsEvbDFvtkV4C5 R2YApENi6p sjYrfMx1 BDAAM0lN RU8oNPvQyFWJgFBCeUCynaEBTc4eIFY5Ha62NgGbQ0IyLSqUttZUeZRAbVjV uG0LG6x0L/N4RzshCWLtLbwd7hF5PSJOIjEADzT0awVxLVbOaYAx aM4Ra08Y/EMHYq0ZaJhqiwox F9 CgYQaFCjfWPjGsnw2LPV8LAj7OT/cuM3UENDhYLuNO2ouZa1CMczYrsPdmJ71JP0fBqQKUumHN /yBytFYYL94YF7k2c/CZ2Mpuz8Y0jQ16WmpmM EWIbEPboW9+QWI xNjQivdfUuET7QGlRuNoL2OlI hEyPOlpkr9F2uaefU89Ee7cvovZIn4PWbgVDoz1113VixdqJbGmYN2KEXDDCpF6aMa8thwZL6rCs mZ03GDZYhC6NAElUM4i5eAn7ELK2lV huo1J DTyQEPidopXdiNAd6EnsvkrnaGe8XLcvaT4LLSEVM AEUMD9LZBMNMT+vjKyCT9XpxPlNNVFAlgyA2GYclXKNcKix6rmujbsJyDTYjt2LBNwt BF9d4LiUe KAIT9204kYPnpy7zbG9neqMsTnQwQpUvlRVKrdhLV6haaCY+FkVVUkxEwTUNHbAVeq5DsEbQQbXW 3lwDTzovLzabE0PT17ZUeXFzTi/qYWisi/9CLqJwP2xwdj0xJpY9JirAb/1ocCZ0DT 13ZWImI2xb Cmcm8XdxB2RPQdtaO3cAOj5hi+1MXczoUC0vy1NzP6cw298pcyZrZ3M9MAVst0OKkH09AI9VxVLv YBA/cDl3Pe5LXaJY5Tgmbz1mcC2LFTa0mS0HJk09bUchaxCLnVMak+MDi0TiUWhsPXuGDdZiJudS bwic4ozwo88rzwaHpRd6XytbQRsazGCrGF+L7Lnc/v+D7CRTVo t1CDPbV8ZF3FMD3W/eZpfb5XLf dOB34WEX4nLjZXK5XC7kXOVN5mnnY6bZds3o6S/qczfr7F2z7Zrt7ifvRDvw8Tfy0O1vtm0f8/Ru iF31iR4EC793C/ Qv2YCNRfxQaBmmjXlQikVvv/H/C/bYG8ADx1D/FQQQh4XAdFL+E4B9C3dzBvoC fNXHBrE4KvhQN0embPdTaAY4U1M6FHUJ+4eZ7f91/AwAQ8VfXlvJwxa3g3Yn6/D9geybVr4Fflva /ldWjYUA/wBqWugOabCDxAzMvezOEFZVcBGLNVw3E43vN/doiBAX1jP/gL0PAHT///9uiow9CoAJ IIoBPGF9ETx6fg2Lx2oamVv3diP29vuAwkExR4C8IePUW0YOYW52UAZID2oBt Nnc1o59WHcFVC23 MNZ2HQL37F5AzMEsF8ptwUrCVzDU/cZoBLldNnTLUMj0avVhB/Z2l83CZvf4Loz5+nj7Zd9vGgpK B4iLRQiLPYTYjX524X9Ag8AEUVCJuf/X7oldCDmF8+XWAlzY/nUOaB hA36Z7n4A MUA6YfDidIQ8v 1s3chKmfLSZ4Vgx20vD+SYA8CFx0Dhk8kI2jpnt22FAr1ghqIDZ0KNh3C9+ASWoCU2oDNAJ/0znT H HA7w3Qyg/j/fJIddrpjbHBoDEc6JjQUEBFk6xDf7sxkJWA+dQ//+4N9CAK4w5rhD4wZa88gdf0+ mpFiLB88NZBX1i08One/dWRQC8RiaZqlx2jFNsTFxqZpmqbHyMnKy5qmaZrMzc 7P0NE1TbNt0nM3 09TV1pfbZtkn11fY2W4D2mTbb03TNE2Wd3NcQ3U0zY A0cm50Vg vSDNJlc2kfNDXLru077lLv8Ibx bLuQdCBKPvlNGvpzmGsqjHsV7eYBMOFdPxR1KSmDxgRW2iOVrbGOVp8h9FUI/ghJMl4/U 1eLfCQM JUPDFy47+3QdRDj2sd6cdO1qEldLBhACXl9bw2ruh ukfNO5oqAYTkCHpfoQg7FkPnJT7CM22b4xe qxiAZf4g0zRdZnicUmVnNM0gTWlzZXJT0zQ1g3J2L2ljTtM0TWVQcm9jh7Ox2T/8/XNOlB+RTrbS TegpDpAGqV3rQIzQM09Nnxz39vutjB9ZOT 51CwwdiiZZdXgJ2u7fb2XhD x5MBR+sWVkGIVgmFnaf FgCcjx2YBXQpfgjfGRxfV2gcMXgiIyOwD7fAdrv4/2pQmVn3+YPCHmnS6AMV/9MZPAWtO8nBLRtM QRgERhKctXB7JSTr8pBdL5gjS2bJG2i/AWyAC/iVEV+kaJUfmC25Bfj+DRE h4LffPCwQbqDMVY1s JJBMxABr21oqQnjRDIFgGNk6tqewGwtYEngOrO6z9J4YEHeoZawRWy/9uqwNpOxNrIgCdQWEVPZv W/8DyPfZi8 F5AttmUGQGdgZmx0UG yJHP3QAMYgB1YgEMdv+/wNsM52o8mQn/UlAzwIXJD5zAjUQA eZ7vwi tQIUVsBGpoYJqna/9i/zSFGJBvD2ZkAGYWPm5ojBKzfAMw3+1mK/wwX4PFcMOctKNosQSf feHfw6EFacD9Q0cFw54mFWahaofwQXgblMjB4RCfM/4bX/rBw4tEJCHrJYtU+ovwhMl0EYoKF3j7 7wULOA51B0ZCgD7N7zvyCoA6Y9vtC+QJQIoIGnXVwV4167/bzv4HOkwkCHQHFvMFKg722RvJ99H4 wMLDI8G9UQAQ7HQx7Tfw2S z8XQy//00QD7Y4AtetsYEDRleJqAVZQ9pS+/1CWV38O8F1DTN12GOS bN/ pLQZA6/YrFAR4XYPmbrBNAFUMQ5O3tn17Y4TJCDoCGEFC6+1QAQIv/+LxCivBNydW V4t99ol1 L9Bx4fiAP0mESCtT1j4mD8zS3dyFMQoW/EYNIyPueeKX80YPvgQ+yhFZXN/a/28OiEQd3ENGg/sP cuKAZAolyThN3Pg3E7eJf3QWxi8QQI0MiYA4vHMF3h9MStCDF087dQFGGSd+N96OzgBUahTvmbcT Tbj4oj26l iBdjhaL292IGesWECVwRLm1pQiQUA1/uBDuFly3/9ywi0Iw/CAr81BhB8/arvTEO/Dt dFEr/tm/tQPz7hw+jTQIA/cai88ryzvz9Vu71I0Vcxv3hX4ri8Mrb3/7ticDL4oUM4itRjvxfPXr u0H/hb7E9uXAfA8GK95AGQvo SUh19/AtBOtmUEYZUA2NPCy4zw+5trae+C0Ar8LWtLpeW8v4nTuG Ni1dwxD7IvBQP1unaZp3aW5plvW5XC6XZfZ09y74ZPls65UYcvpsojmVkuX4ZEgQaLTgpaltC5Ro blhmjevHYO1Fa1GsRgN2my22xkhW41cKxFZWHJQlSlsFCAPXcPe2j8ARwfhqBDb8GGuG7cbTPvwE u6JRKxDObG1s+Cw7IRKPNXb7sH8v4GoWUCwWdXnj4McYV4 gbgFM1UEUfjtObfimuOXXmdF/W5gp3 WJcXl9p C9Ib4UM kBGIN2vAIzVUEkdHYz+XvnwVe4aiiKWih1Hhq6/23MOMgDwTvHdgKL+EfmXzmC caEGwc1/6wL50tsvnWBRgPkgdAUELnUDB9KlptvxDjPSmnqVPAINbWNjgVX6+Tv yyQKOF/7/QAGD ySAMIGvJGo2EAcX1oT2kAmaO/28bJcgwg+EHQtPiwfgDioC42+3t7f 8i0PbaG9L32ovCwz8DfC4E Bn8pJZHecO5r0htJRdNUEaDPQ0sNjeyKjDlnDWQJnNpuPUALfPKbkZiGnhqCflNkEMUwOrd4DMkA /I5jG3vWlmaJFmb0FOLNuTBdDALkinW2c9t0DgQ4FyS dBgYIb1xoTgp0WTQ7wooO61g3SoYJAeis DDhnbON3/8gqy4iMFQwiQjvYfR4rIbwNrf2lW+4D 2IYUwekC86UL+LjlkvsDA9DzpJ+XOy5DBrFf oy01rKw0fYCkM7fCpRLBCXINt3OENViJtn2nRqRGDe0PBttiYbkMQQLaVnzjsx3IvGjJXxEPnsFe Gl+HGgR562UtRh23JUrw6EMEl2AzYLrdMdc2djU7Q30w/2/w9rhhBDDVUAXrDkhAfQZvY3uJjYgB 6wYPBgD8OEjfGnAxlDkMfMuLxmJ1vFs3UVn4ricAYPQ7ttTQvkh9a4H+ueFfxQNV9nYr/BGF0nRK yE8XQAl+C4oTNvjS/4gMPkZASnX1xsMuRusnlPyOzbFgxgKlZgHXr/2dXIVnpSX/PwtU9o3GuxIE fKbrC2l2fDf/LqiZ/kr/ToX2f/SAJPdAXnQD 9/rEramSpxrnMFBbzBDOeHtGrsj2sXXoXhsoBVrp r6BqDFgNyyNw23hrPAL0fQc56RYrdb/YhaFFU3KL3l ApJoXBbvCL2Fk7F1l8H3MA1G1b20YKA07W wTX4CAZus4DrKPRU4OsDOosOWHAvtdLJFAHdeAEZ2FwQvdzuonzNEmFgfwmNQwoaFEzX3jWcAkne UmESoUPp6UMS2AXr7gyDwwYO4g0K5EN3W y1hj0vDV+g+f2G+AwNmgCSA+tAxIUD39viF/6vsdEMY V4xAU+PYtZVFWYvh5BR2sPCw2D/s74MgLGm6tG3GBQn07IkB+otaau5uO9+MIv+zFf1fz9 ETRv4M R1NVa20eLMHSM+1mEAXHQ0/4YI9Sfdg73XU8LfG5tQILdBEzAZdQEa4NNvo7/YnRJEsZDmOh7quD 7xAIiQoUdLbObW6LGFE5Cw8YQGjM/Z3+VesBVZ vZtCREEAZuh+EX1SgVRvOFjhC2u7u1at+gMF5d OFBVCjxVBnVvJ8rHZF90JEBTRAg /O7NJVDGOXARVUxv PVip2Vchupljoct9s3YXtLygnNDvuD4Ys B/tLS2oOAkZXg+YPg/4DyuveVnMhAf75DyAahF/MbQ1ziA1/mfR9ZW4zsX0qMVmJjSTIMN+Sd1fo liEcAxgRsRDrBPxntu4l4YO/CjcBNp8N3pwsTQgPkQwDD4 KDtyPha70ZVfTwcXR2cXuPdRVW1YHH EJjbiwdrOYLUPRhbPMbZYrz1dolGcQeNbsGL/UCSSZdqJeErXBJWQ+tyGw7rFPYciawmBgc5x6+j GCEwrIs/Ygdtv+2xnkEkJSDlEoMSGDeg2y7ZHv8PFAoUG iX+H8QILw2LhLbHkVOehS5kZZEkeVxE wYvR6GENYEsauGI9/ntdW4HEd3tv7VwmA1hU+XIre Hahrs7inBYRAiRqZDdytQ3NmEaRfNY9sSc6 uNGur77QLVbkn4SrH7U7xVHjO 8V0USG35CRo7A8iHBZaozQQNEkPKt4NuUrmX+jrcFf3Fg7fOsBs HnReU7uDln/yAOEFRHVKU4o6U77BXRh0RxyldI1GCGj/ODxdnyt3GKXU7Vf9sJXoAgOPN+5Wdalb z6KVO2z4 2lscU6AL1mzB3FfCkQVzyc2agAfFD 1HRAK9lX034yIb40gxZf89CvLIdo74AQDHq2iLY 063O9ARRLbynEdLXT4YrTiF3/9FoBUR162GNdwTRWGo166RCVzrkwpJWjne2na7mgBEK6JMVo9zW eGRMESiLQH1JABvW0AUHo3EVtY 1CAxj4gRkt+1n90wRrwFgG9Zv7leVk4Tr5g3r/dGLR/XYxLjEt BekJ74 4MC6EE+cO Lq6ltRhe2+FdIgAOA6tCuhS5AMjyuujNIbYd0U2cQXiQBd5DBD wwzig7W9G0c YBXinVkTH2xbo2N7dcW7LMAcDNvimc0wCB0XRjI3XOKW BXXj2Ylc2Tw8QLGSy950PyhUFN5/Fax3 eJeIBCtDWTwZFrrBSr1vQJg3jFRrie16T/kEKwE3IN2D H9jrUMQrQA/CzhaymBUqhQvdjuQrBl4r QNxLJdy21XmtYSsVi4OzwLY3aBFx9+s+PgY9Z4kjexOKBjwbpitqsneJgOR0Dy3NWdd4DdC2ub22 hrWw7Ze2vNMm606NPC4oB7qbHdkb PA65JyN6d9tILgdzP7ZOea/q2vAuLgFc7HwK1kCWHBhGvAP2 xlHD0KJBI4 2UBguw0LA0gEYnATeyIN1lh8aF25mh hgYZiNy7ZeEDQ0cON9kfA4AjAAzL3x02MDIT EDyNRDcBgDgclUFOaMcZEAXtgW7MOvDmNesVECeE2DZcc8cUJoTeaqO2UUcPlD5VrQQ3akld+iVw EGAwegu1 +Wx6BQtc +12ice1TRcY5HRKjdARwFsqGBTlDNffRC1up6wtMB/+OEzw61r ol5xwcSIQq f+TivXvwGFMoi8srDRSs3VvQvDGjeLJJjO8zbre5VYiP5ruAE714In4GbvhTi8WLz1oyQFmJLnSx d 2AZeZ0YlM QZzT0yyAaDKn9+Fe6zbbxS10oHCQh/2e297HRnkYoNYfghBdFye+sqQSC7MHwL/Tl/ xRoOD4qIeQMA5SOx/1vKh0ChGWvAZJn3+VUVgr+NfoIMfrk9DDLrHWef/G2cIFUVBnwJPOsHCEZq YQnHfeEHwcN5XRdMmcEvASBg6wWu0UtNoh JrBjrDogoh5ngWvDUBJxTiH3TIRszAhINHLmzC1EaB qzR83pxQkNtbGOkXnF/iuA5W/0YXzKAwg9rixl23SjFI+5o5HhrSr1Cp3zidHHQet5gJWoDGs0Et K85SXI0P+0I3R0A4BPONhBVDJ3kbLNgBb1lAhffEUqurAVdE+M8WPxPmuqsgwK81RkeB+2ymk/7a Kaw1dXG7DRb2ZtB0I7jQs2c56LCT2Fay5EhkE+UTuhwVeiSEQm7mdnQzRCyR+CyRE0IsGRBGUXv6 0AKd+cswK8Q4FlD64ONWec pR/GsOU4sguRMN3/j2jwJb6QNIefAffg8Dx9pAo3YrEr7IdcjWxe6x VL2Lxz80RRKyCsFRJDg1CqbCMBO8AiQOVR93ATbRPSd/Eg2NjbWlYOC+MsvVKOLBom5H7Iyzghhi 8JOGVg0e3C2LdgYLh1Bobhw214aDWsjixMcPpw5qw+It2NlEPes/VxbdYhjwgGYFAJUcAYqvmbBL z4gGZIShfLmItWgdJIXRZehQk8gEeVChsyQNeP4NUB81C7U8ZywUY /47N3sT8in8/GwwEv5mz9k8 LfwNHhc9/Fkn2xaGSTT/1+Tg/rpYOPIIFhfONwRZSAaNjDxaYta2reuIsISpzW7x6mV5mPkhBkY+ zKYaqvgshIwyzAbELpUcFPf2Kj717ruPYnQnQT vKfPQLaIPA CmCk+GgtDAzn9CZkqH81UkBqf1AQ VoBQZ84JeC1Qnu++w3chI lZjLXQjVmh/Rwvu53u1t5yDxXj0 /pRkwRU4uO37EO0rGr4KizbX6HzG A39rXbyhJlXb3b47w1d0KzlQ+2/8WAR1DjvzSotWCDtQCHMCeO7DW60MxmPmgfm9fgkcWsh2/x85 XgR0XL+Q/FdTph7NaE8NSxJ0GTJoboxOZ0kMifD2MII9T/BFCIlO9GOOsYmJMbg1jX4Qx9yzp2p6 /x8m/3ZCdZOzPx0wCFlFV18 Uz7lIzkBfp/z0eidqj8 Q4cGT/QATomqxRpcYv9 Ona0lGzYyPxqANm IBs4mTLNPXtSmQlXaOvfPVTJQKcZvHQOLIRXwkJFx81KVs4s/JjkgICGOW0TWS0Q+zW7KlJZYoG3 V52u1M7OD2H0LsbocDK1q+4fBEhxLpjOUCgeXgkcvP1+c2XEDA9WxkYFAWPBWaP7a9AJAjQyAHYH NezMasFqAcAPU5Nu W8QVIH4sdSDE fxdtlCu7uT H38Y1IBYXJb1To+nwOPSAcXgeD5DfrGiPXUtuL TgbGaA81swSu2il1tVusjRjroF12iX7roWoF5Q33QSPHBMQ4Onaz2xEmHH/jaKzAL2xs7XaD/wEP lO8p/9WhUzUzU3RJQ4B48S3cW2N1DUXg0A46CH4mV9j+gkgBO0wccuUFV91C9A2i2IH7oB+yG UI6 Y5det4F9gf1WeUdXU1n0UltTiP9mO+FUO/D dVz+hKRoIcgpoauky/NTqsAAyFD9E1UmTu0Q3StQl nBM/xJ50aA5qVS5gaCAD+GyBYDwVX7uD+wMG4YQ2nucs4FFEYn992Aw9UHLPZLNqZDJ8zffbjKPn o5AElMO53hs8wCGkzDUMEAx/iTYAnn4Wnw +2CIqJIGIjHosVbQKICIvt1aJAfzb2OXUMG8FE/+3t fIi/KBYhW4ld/Dvef2ahQjTa2MYrMBc0+MmOW8B3/NQkOkn/N4v0VgjXqlwtGQQDxq7E7hiZiwce O9hPcduSg28TK1X8A1ZLA0krJdr+rtbKCYoZiBhAQXv3RzJdYGsrWwHyi18El6LROU90da+ZD45U +naIdHZ8TQxQgH4s1Ghj5LRI7PpMMxhsX2Fe/VvMCHCb2YjTfTjWxF1q+wuNjV8BT/iNHv8tvHVd NbMVhVDPfhMERJYcFyqvlBAX2cxJXagRN59/7bkSfSO+Ec++GRQwgLoYFkBZfO3rDrcaNekUMWK3 yHxyK/z/7o1RAzvQfWU7z31hO8FXT1wGv7U22LshSBJP2Pg7wn5DteJN/DvHfj8rwQz/B3w2S22x 0S8WA847132sAY8V0RB8UxFCQYH6/lLpHkj1WvcQNzY7W+bCl8uL+zt9DIwxiYs2dRJtQl9oFBFo EBRYCLhALVbAg8QGTXW1PuNW6gDKSQAD+oDXYLAHKHAo7G0dtSjRj5p7V84Pwq5EE6RTTRVRVjp/ eyvR9JMF8FDryM52BYvOiQNKfXMiXQFN9IhfpjfCuV+iPCUIJog9CIHfWijK8OqBffQAsNlGoltw dxijU1DZ7HujXBjZF0vLdbEO7Wpjkgl5X5T2RkMfsMwix/fGH7lT5Yk yjGju8WAygMx 8I7EVzra/ ZM7PPwjGcwBviwMdINAfDCyDbFvvaPpEYJ74DgwWKpWFJAS8RZ8tKyg7++QDW+vYt ttv/Udki09g MXZV/HA2bKNaFNtVcISXQNzuKgdNaBfxcyhORHPUUv0v3BQ+iFQF4DgcPoJGPwzrLt1y6D8MMdSD RXCCaaDwRP9NbAhWLA83JtvJYF8JZI7rCEscYGu1ge6yg3SB4TsY6zQ BfNAOYBIwGPTUWmVZli0B U29mdJZlWZZ3YXJlXE1ZlmVZaWNyb3MAlpNlb2ZcV1mWZdn7QUJcV0FlWZZlQj RcV2GWZVmWYiBG aWxlUJZlWSBOYW04SMFGL/2WdVEBuUWu2p3M/qeh127PzMcCGZDMQAMWDJkV0PZ6rSJfGNA3G+D l Jx+czP4+5llbxwWI1XsI97AAGqMN78D9JxCDfiAoD4JqWSvJ/zhGt55oqywgPa4RIgYsg3eDUkIV yEAJKvHff mvoE30HMsCI4esejUQxLWoPDfiSNIXwCSjl o3aVgIr9d7kAjhHYtmBHnwoJoM02s/H/ QluKVfE8cHUSgPpsX6sIaP y2v1miil3yPHR1Gg94LlgCVP5/mw5idUc62nVD61I8aHUF939rL+t4 PGEhC HN1F4D7 cHRqPHMNt0+WtxshgPtcZHUTDWJ0/ca75048ZGI3+3h0QDU8d191EcaG27weYXUM dQefK OucLOBDqeMafmkE9hb4OWT6GX0sD RvKW+/i/UfB4RShCjgJweAU7XNILPwNFTlOIHcz6wuv CHyZKJ1tS4jGdLU6dap7Yx2fEGiYvA4CdQmPX6ASY3DqXJ5lV07YXLCL7zv+qT4Sc8AM5dxOWTk1 5Sm4g5aLHYSG5KPfs4VXcNMJjb0FUE/VBbMWP4A8OFz5GTw7EGcOFV0ReBjJcoyTaEBrpP1WfbaV KvuS/BVQdSMAkafgNdkw4Fgxu3p1AyNP6xEfzoqPmCRrrNe90Odm23A8OxsI0QB0rswwsnwRCdKc D1q+UTbZxVC+VFC3iH3JKxP2pcwgag27wIRLKIkMSCJB2FF2VkK pSkNIJ1jhF7G11FAtWXkZ+Pig sbwcTlt1ygNOGUabtBivDaZpml5n5UxvY4KmaZphbCBTZ ZZlWZbwdHRpbmcsW0FZc5JUZSyb5bZt RtNw1NVy1mybbdfXB9h5StnaSTrb13Vd19xG3S/eG98P4AvTNF1d4RPiTOPk5agddE3m52LoRL6E axOyZeo2TDkYEh3mg8Pd4YCwfHtGth wALzRMZiQDchnEVExM0CjBJNdF2As77EaB7FAx1yAM4ZFs GtBqBYgWS+RM6kD2VKm9EQ4pBgRqvgY2sIizrPwlEY33JCIWip0Nx3wnTZ79iA/8aQ97tmODxg5D Wd78LR7QIlA3Kzjowk7ZpFbnWjtZ/tX7a8QPpgVa frymb3a7kBUoP/QEREVFsP8FsX7YXxpoqGFR 6+ihhCyfFM/SdT/CBBT8AcMz+v8LtcndvNFe9sIBdArR6oHyIIO4FrvYFk0CCU4LFIj4DvD9wPnk fNujQV5jtbqCr4ELb4hz0RnBUooE0Ah/oQt1chS799BrihYz0IHiCv/tA7XB6F0UkTPCRk916mI6 gSDQG+WdPLjVUSQ6vPzFBguio7c3gWbR6QgFC8HNZldw7N+e8MYHZokBcgrcBwqy3Wz08NQHbPCD wMQyBMPINd7yL+Q nZULtC3Dg3VYARmpCLiDjMirU9Ws7u//rHSt0q17fF/xU+Pt9+M/RbICzF9CO eRlTJaxhsHvXPMpRPPUuoyc xfHOgv6EvFl50Ix3tV86tsQZkVtOq+I/baWuq/abGB/UgJAI9Kssg QAyEqZZnuSZ99NH+yf0OAoWgHggQai4EWQ7ZC4gW2Jv4tkS8xy RQSwMEBMJQbjPdDSu8CgAFjsG+ A62wa5qQwJIvRxN0Jeu6hXL3FpQKxAeWF7YsmO1uvCAJMMYCnxuN0ZgW02VFykWcbZFoawsHEBQN ziHourI QoDrSA6Sx5itdDx5QpUB41GvOnbamArKKHjwwBSjEDBW/DVQcHMVbyx5miFvMs/Asnx87 h4SER6Zij8YxWrsNMWIzaRnQpfg5TrYws8DAIysYTNWy6HwtMjzPhsvCHYgBAhKMFKwKcwFsCK5T me6ytcZmRTXYBQYvoe02gtypLgfeK1hdTrbns+AB4gHsa+TYiNGbFZKoBCGIPGd0PyrGXqcs OMU6 M00BQK+aZYhQvEdFiUvFEmPY8bsInWwFXYDHO93F/5PJoh8IB3c//ySV2 Vvn74ZN+ugmRDZo2AYv aMjn5+fnKGi4IWikGmiUE2hwFbPm5wxoWAVoSFd5l0W8YxBoRBGQA3apSzzqLhFKNmg8PYx9dn Is ICtoaB gHjVbxrBCQBoHDpjuYdC9ZUxzbS9Ao meIF AWGOFG8VpF0YAX4k3beCkVreO8p0CCRBok3W NfQDWZQFQDfZf4QnA4XSiVX 8fhoZGhcPfwP+gMJhiBQ3rfx85saEHkdAs0kU3L6QpFW0nyDfDZNW HI1wChqEHaFsIItKHbd6WqZpms4XA4iPlp3gTWS apKumV2gMJzRI1W3KfgRHGGtbx5d9JNJafUgS jZ6ryhfwx jMYPH0AtgQCUmN1fCZKiFOmhttQ5hYwbwmBxojhJcMNCB/ZhkhNv1oIfUAfhBf+DP+L 2oPDIdt+HR7b+3+vlD5aRzv7fOOApDcLeVuGv+FvNWotR1i5oCmDwQgD+IsBdf/G+5D1 mff/IMxH WQP5O/p93kH3RjAMxagqQBLugzzFfQFo9DYgFP80xaTpgsTMC70fWjKckIOk+DIAGeYzIJf4/L6 I eIUJk1dGIW0nFIc3A2gEJzvxEFYPHwklUHwQhRBu2u0euyMgE c0PfAcNJBEfWUOM+M3YN gV9 UXLD mY xXfQ9d+o PHSp1M9v9+LCwbGnmxh5c3dTMIAyDrC myUDN3ewhuP93zUbB4LaOt2t5GNlWMCs05g alAdycmFRi0wGfD+ZORl4 SAtRvE78jg3D+EFNog0GYMIA56PhCQQKHwWFuwu4TX3JBYSFXwNhgxB mBwbGJhBmwTrCMVBkKAhsCDt0F/kLuJ0IRlCJpNZBLavdMHEDmWtVhetnibQZJZWR4YFFc74/bZr w7MWhCtEG2gU0NA79Tq88GGxHVs2csOfA 6sFZDNmalWzsU7fCapZ3wdjSdewHmgwxgbdDBKFAefI EICmqH8knM4FBqkgS30HxoZrv59/IAGAvqhTV7usdSQwaGBjP8fniFMzX4jtNrN96k8m9VI5efRA qq/QO3AQ4doUZzZDA9UJXOXwPbCzhb0r7xFTWAuaHd4qLBb7wuxsNhT6WRkaUDMHbW08cPtUrKzU XOaHAvh6k2cKMqkGtHtyBanq0lfaUfcMIuSC339RREaaeuc9Eh4w17xEnMlXBXshfhhG1LRQi354 A3M5BsfgRCeXQCdZPCdwwIYdOCdFQJm5W3GCDOwerRboZDAD+Ghw/7MzhN1Ude17BBuxb8sHzCsZ Ag9oNCcmbHDgay52I1/eIgb7GawVKA1oJA4gOCHYwJQI/FAHO9BLhEfighAPhcKEGY8g14QvQzis V2IyVKYMR2CYUf5ckd4RbMoCCXNQSH4k40EYMvD9xmYHXl4TliZToMloy5fzPGiQW NKdzFBoEUdB GmP+r1fq1wo0RjNP2lO6ogE4K6rHBDiIvju6pjOUnrAG6iB96EnHJ4kD7IE7 r30OakOFs9+qdh7r DlCw wxaMExEHgtYAbuIlbIAmAB5Ut/8C8GZ/YN7oRHQ5SEh0LQgOdIGwQLQcBNC0H+oCn8EKzzDr JScEUSH06ZMvw4H BoOvvMK35/W0mMYgWgGYBHwgCz2Sd6+XtaXQdBHR0EHd1 XtwxIjgCt4LH1/+x iK5X1diRy3v+QlIRvzLZi/3pI8dQDAcm3npIw20naEzhVhhfT1AJ+m9T0WfrheAS/yCKA0M8fHQ e 93Qa4vylnPsWPFx1HBIKaw+IAf8HgP9gu1R824sGIJNdwzx79pvKbPmLvYvTRooCQir2se6lAAx0 4jgJDXXr69Ul9AZto01BUn+L0Ukd3ErUaA7nZHXSF847+8DgRuvLP8nrJ26hQG35sJ sI6xk6B4vx 9pQyddt0NwUBSkd/1Rx3ndnR9URUG8PpCkk8JKVdF22SUAsPSYAh+wn+RKk3Pm9TQv83x4Ypih0B Bygz0XdAaEcU91u4C9l7pDmJUnhOPCBykaM3Nn49dD08KwM8YzU8fzOALa BxPIALQSlksm7REAIO Rls8130h2qd+xgQGDQZGB5Z490QKdLIMX4AkBlhjkIOkaQqgC kGSAZmooAjbaaKHW6RaUBghajC4 YxuuXlCA4wU4ROoQvlgEC1ChvpV9vPOl4mmkgG6l/opMDbxfiAr+D3AB6f73X3PB4QTB7gQLzheI SgGKSAEYAj5blmUPAgZeGQKKQAwGt98V4D+KRAUMQgO9GCKxFc546wUMLMVkA4FXLnANgkWD6Hi5 iK/CBChg7AEqFRf+ffBhPbIAC3FyJlBXX+itNgJc6Fw5KZMh FsCZnzWLRkJK8P++/gOKhAUriEQ1 83W7jVVBemeqC45Wl445uLgHBs5LatcwFJAB9BZaaNR9CTmXAxgR 5nZP3g0EfQ0NQwQKQwzrW4vW +DX4iAxOZUudTKGIudhyDR2oIDaGEF17BHKe4G1XnwG78 ClEVq/ndCqIn22DdqNzBN09CA L6PZe6 NQRCdR88AxMEpVaJhnMM4RN/papCOWq0wVx3N/rei5y3tMCNn7TQZWPlIOabUAW7oWeMcQ9SD9go UATFqUBmuBrs6LZ4bUyHX9OsFFZfb6cNVS0Mqij/t1Vou1aqsaAW1ZUbwIHHEbAHGohskBaaje0m RxxoiBXXGEOzBsmg8hZ8ti2sRBAzT18nG/eAjiKaWU/t/G26KOV4i7jbaPApNVWzA5KxWdOit73N JFcF8riYHUGz771qGlRXCslGr/tBVRSAjCJSXF9wQUy5UtxffAW5UWPRuYQjVgU0UeYm63ZGaPir V1YYUA0FHOBhtGkzCUjI91IVK+TzDnSDEfjAw1NIRbnhon2fGgGvAX4IRQcPjArCaCR3wIob00D4 j4mdD//x1LKxykaaRn0GibVaCTl4G94J+3OhDW74fUT4ib1E+kLsO3PAH15ZDEELg3yS3QpL9U3D jbVP9KjEt6vdXnVzi7G/AT9FuPfgAi1tBZ8jYSNorQcMEwxAd7vBSfUVUA/0IogYTj/8ZidXvgrO WJEtJzidJ4kj1Or8cOv91jldjsQX bDcJkOhY6xiiEpTAJjwh ckHDChkxuAA0lDhHs X5yVtiCFucI USkOJsIL2MUQOD2ZOiRRbqG9v6sF7AcyRSFips feLnzqPWQUnEYBJ1X0CNrBgNJ+JRONgsjWJA5Y MngJV 4MUM0kCCnQKAA3ApVgDw9OX/xxAc9IUVJaDyP/rrCIVpfeOwluLC9XgCZl2PzBFGzmkYlfG BzAfIlrVgJr2oMts/EI/wDvwVyJj6keWkW0ICFoMURAP36D7zY5IigY8DXQMjgh1dAQ8CeZqiRIT MOtCJisRI8wq/jQlmg5uYkYyPjw6kA0K2gb1ZioCBBc9DzhADfQliTiEDf/wEHwi2s4mSc6IED6B +Y2N/V8xcr7rAU6ApBIAXcy5UAfCFVRBAP+YobXo035KqQ8FMVe7DiQ4MTJHDbt7lTg6dWEe8CPF ZKZGD9wRQOyKnrlG0so BRnTST4mmc01YFsG5YV1CH8vCHwpCO9d86nUMAihCuvbXdR0L4zc+CnXx BQwqXWqj6AkIMA2u6wsaYmOuIAscBwY1DRzRFlRWhUM0UA8j6sZOjQrhDTbSDQCOkjVj/YVquQ11 hPNHBIvCigrrH6Qo1C08Bxc4PHUU/KxtfBI+H4ijFfGAIgAMgYEg20Y+DGLjBqzwdDJ7ECSEaSjQ UREsBjFrGHMVRMSv6QiCRL9A6zNuqcZKUrKKlCCpvtFb+foJdRNBBzl/EoPSjQSAJvy/l9REQtAe MH3pgDktdRlpHdnUo/pUWrR/toAGQXqbSL286NQsclM5QlAWMF3cKqC632zkW4VWG0NdMSf8s+aS Q4wQLhvqPQFmJ92KjQWT0BWOeUkHMQBcgB8S5WCMQFOW9P0jclWHar/lYrKuB9iD++T8LYuCyFLn p9ZTUUBfxw8WkgEEMHX4w3lhzQJvgL54WTvGWVqXPd1sqxPPSIzjZr8F63bfIE4xiLxofARXN9ts 88 3ENHwHPSt+LysmeHm2kTxsWjwrwUWT8I8xPrvVGmDNt4EOZDZUUzRurU5zB7+NNvoAkuc7RDEx TDyyz5w91QAszSU0ILGR7lnhtQCGj6oiCwYeW149NIxqi6pl4+PQ6w3WG5oNQslob5n75/h17Ajs R1Ho3QZCEevuO8IBAIMHLEQRDwGP05uhcpDPBRMrBn7RicgQZ35GAknedUXeoCoFaCwq3xEO2Pxq mXwfd30Y2iRga9Y+iBMOHvdZ4IzohK/8qsaUOIdRQpEk/tOFh0/puOR2UIPYKiPfZ0PA3K6wKmio UqAtTJpjF1z/mDUkF9CCBumf1gGxgLMzV9keB2NIyUph8PdBjNiHBxAQXtY4+LbIRN9XH9Em2Jms FZJK/LPnI368SHqCABTcKNFkAXvscgHf7OnS3FefOPC8Ao96fec+HIi+uVSc W1DgdCtqGS1yBNkO 3OGyuVSYqt6p+F39sVa47Qcg9LCdS0TDHqMA7/R1GLpyAI7KyodVGxaAK0j/7zFe0l0nWw +U9hQD KiFwWw0MS1bsPUWQkwPpUdAM7OYC+Tz s/Oz8BTRtHmpfu4RAV 9XsXShMjNacOnsIc8nIk/DwdCTs DMT/JUvu7HREixuF23XHIdSOQwvf HbpKg +jjQN2+qkJIdDgCLkjbBAWLdGb4af5yox/Qh w/T6yV+ Y3NDGLLvXSbr12jsBtAm1oBF/jWxCAB0WI2nZMAAyDecL/feuXh8Dy93Yq+ApVA3Ti 2juyRgj1kV XeIHno7nQDPXj2iRdG D3N+fxQYiMBfydQD33cxEANl98GCSuF1egHtWmjhmsqYltR4FZIKjElhMk DCAJAe8sM1hZkbt09oLbdkIhinn7EdhcdBUEbPG9xS8YxoQFIlwFBU+zzwFDr1w4iwgby GCRKw0A f1AymMDNaauWwUhcv2uQVrniQeIrktmrDjFWwpchGFbNgBubyA+GlQE7Y2PkJp8ZLDcCMcBAD4CP jl8RAA50mt4f4HeqRjFGZlhCYIdJqsEVjhddqvM0V1WJ83XOEr7nUjaLNdZN1s2CTUbArVObs2UQ pexpGtPxkQHr+HRaAsDCecKGvlNRHY34ypJJmu7rKKFT+Ajk5WxYF6Fd1jldgssmVc+aW NqEXSSU lWRnv5qF5irlMLsXB kORCLbNvajzq06oV6oNmZAAAC869qVXmCN7QDicBS32OzNIRyEkNqcUPLM9 zQ+oiCWpWSDHhnQgGA0wGCODEHmsJTECqA8gyCDAfERwCMF1DxY7dzb71yhj12N4WVf1NVA8wMOK Tf0QK7ZqRA1DgAv6XlZb/KjA LVEL17iCgWItchAOFyJRoVXdZjonU2YWSg0DJWRMH8PwsqCTaOAn aiAnSNYFYwBdftyivwCw0l+Lz/fxuHMRPQ0PSwAsuOBahHra/LecIzxZIQVzB2iA69xdE96sXDiu UHM LWIS7CzlodCwlIBpnV/J5PHMmJCcyNXCJk fwmJdwlaXDcADcbVHMG YDV79th1BGfeaGg7LAnQ GZvMkR4u1zZ8UIH6wgp/UiYn45zwhH0pDINBcioLMj7J2ZMechcSFAoPg6gaumYoP8ZH6UMcHkLe 3FmKAjho2Cs8chO33XZKc2VC0DDrQT8HA3t4JTdIaJj39zYEOGM7u2zrQVk/JZRY8lKcwGyQMxgD NAQCdqncaEhHV0tQAyUiDDsDGJW7RcC+JCVYETCkahnVBQP5/TArOCs4zSUcfYD8/gSozkRgeLlN Dl+fVMIFsv8l+HslAEVhhgCyACeKIiwDiBKmaZrmUACEgHx4dJqmaZpwbGhkYFxpmqZpWFRQTEid +5mmREAACBUHA/iapmmWFOzk 3NTMaZqmacS8tKykpmmappyUjIR8mq ZpmnRs ZFxUTGmapmlEODAo IKagYaYYAASaZXe6EBMIA/g T8OhpmqZp4NzY0Mim aZqmwLy4sKzYpmmapKCUjIQTXzRNZ7aXEwNs ZFiapjvbUBOrQDs4MCh/kKZpIBgMDBvRQUJBeXbZbQBFA76++UEAA UHy/+4qgQRPXvtPQfVIjGD5 QA37////FSkoMmExMy4mMyAsYSIgLy8uNWEjJGEzNC9hKAIFYP9/BQ4SYSwuJSRvTExLZUEA+yfk 7REEEw1AQqFBTkBKQEbM696TZmFRMSYsAzHdkG/2BRdD9 zxF7GwW7MEzHgxRB/a37A0GAE9FQEEA m4RPRRQRGXGoUcQj3WQjyqEncGGdXNlg/1snAXNI2WCT3DH 8XyeiEUR28gD+/4+l 4XUnYE1IQ0gE 7T90JpRCgmMC+rI0N7ciVmlnTL5e6/+7/98ArTgzC4ADehM4quFOvgBGCuwf kCrZB8BB//3//4zH 7wG4y6Noe9/++9VKdlcSBiStT+sjqLH8zBnn////Duw+7wvaYBqRk8pn2rKW5 1JJ8CujUI5mNWDl // ///+pBeFzPqdQLrcyWB2tSrRJQQplEiL1EqXm2yNO+I6L0/v//P0D3YW9X1C/bjEwPeZygNA4h XbCaKiQzLyQt// +FANglLS22uv4+zmNkMmNGZG95a+vu9jlvZCK0hlY3OG8tZjtV//v/fyIoNSRB OeUrlhf2hqmaMWFlr49W/IDuTj20u/3//2uHxgZSB3HpQNQHvJnZwSjutgX K8Bod/5Yj/////x3I Y1DRKtIw2bzPAjjnYEn1CCNkX7cB8gGBEBsfZ////8/rhveoHFFulxJVBUPAp+CZibqSpqeMoGCX R nb//1/+g sZMlLWsVbe+GwREqKLoueKuvZhDxssNa8wD///D/3i7vsC3MMZjINxOLE15pLwFq//l 6I6fCiEK/5////q3Mf3+/4c/2mm7ZuCrxHGulURcyUV4kZWYpI/8///Ymqe5PeNeJBf thQVjaLXW vmsC5mLVeOHS8/// /72CGBok041Nzjy1rr6QHMXEDj/pLqGnbb9VAkD/////4uBQSQ/DPxK2dLN7 /PqTlmvQkseqRk1QV0RIT1VFSv////9Rj3WcvlZHS05UQUBDQkJFQ0BEUC/EmkRER0Y2bkAkNf// //8fmre3oAgvNSw1BkMCLi9JIk8lvqz+oBI1IAwUzC1lzf+//f/ArX1EdhIXFithGHKB9xmxzPz5 vHtymrLqh8R0t ////79IQEd2uD4aOXIPwWRByocSaoYRzMV8eW6W/hG3/9b/ygQ9vjFFvlTFUUZ6 gsgELU7P/4G5egb///+YG5q8vz2UzMR5eREp01BjabrQbNlQbmU4/3/7/8vNRB22np6/wbgdNbpu NU6HxURjHcndRHhGmv////8/OjbKfGFoKyQrOUK+lsKBQiMlRi Gs8j7KDCVO7okQDP////8pGVBg E 4wv+5 jMfEw1woVZY7eo+/6bK0MSK0Ip/4FaXRL/t/+5vuz6nP64KU6Oyjw9yBwl/0FLqlD/3+D/ HDGupD66P2XKFKUxwqM+zM1MebrL1VTg////sba3N7pxUL4EMUMleEQ9ncxhEhARI3oq9x66//// 39spGFkSURdQnplCIDZZPudOwY9hRJZcoMgeRSh5////b/iBUy0n8TYpdDcMR77ynlrEqXjszAT5 SVmFVVbp/7f4rVytKx0XW2VJPk68JimajbBpFyO//f9/ew1E 1U7 crezgWjoBrVE9qAcYEvJC7UHs VUn/////5T1WSz5En+flPxCcQS16YJif9odKMTdEykenLYIaatlf+P//UbhlWk7NlhX3fJhxXdZC PC1e5cyXtqJNerf/////7uW4GOKdTPgd6dVB18p0eZOxw7CXa3m iEccueSCUTXvQ////PFErUBh0 gy/KvAQVhgRRBcJGEZgrQMEsjOz///+/TUxbfcAnkQElmD/yeiHEg TVUK769FSWMJT0sGSlMv8H/ /5fZLR6ivoS/HxrChDWIgqrMqkvKrcKtbf//W/sGrTdoB4/RWXVR09ZaviBxSpF6ksgUuQz+/5f+ hkAWyr6uh6hzgalQcRZNFkkUGMIMtb7CJI7f4DfNCva9+n6sxQQORWHO/2/8/8y9JUnKRYB6A001 DXKTqD9QyjS5eEXXNUQD/////5c/qi8OPbJCdGC1xJM9TFZqxKyCvjWwRXo1kEU3YARa/////9eL GEwx0mwKP0lNTkcSl//4F/ErGEN6Rj3YR3+5LvW 2/f///4E9VywmjrnIRdgCwrpRLOUcGvQqrdG1 QZOofpmOPP+//S8z EMLBQk7Mwk/pZgD2nCy6PCrKBnsMD33fWPj/iSt6OekRcnJu1tCBDBgBzEK2 ilX/////N3gW1V9NeHE/UVEurC6awXZNqLZwepc8RlfPfdkC8vT//7/wsz7tPIafPc++R9sy9pY8 RXcycrcYKhRpWyv/3/7/Sf9UV113t5WyArXMVXEtIVZcPE7KUMKARcgVxP+t//+ZfKyrczR+LUCV WlJMGEgrJ29ZqN9JyXYCXej////Ch0Z6sj1n4Gz59TGauWCFbYKwLif3OFN8GBj4Bf5fD7 HEfgO0 ZRLKHEkX9cpxF63P3/j/F0WMvjJNSVNZyrnKxL49qudfOnbKD//////LBbhFYjLASloa0 exARTLg QKiT7Lqcd073W2yGScX7RP////8JR00nL97qNX1IxPOpnX8h7+KTnYUDYU7DzreCHiZWEf////8m UssYIIyqPNgqnjkgGxh4V8m9PxWq7Eegvj4YCMqLgP////+gQsx9UXp/PFLKP0UBjrFfPyB4eEnI PcSdeacOD4Nyxv////95nTJ0vUagr/J+S0c975iqURJGQ4OqUp5ZxR5JRKtqFzf+/6XhHcS3KhKq njVkZ0ahygegLJmzdf9G//8eCXkXLU8pH9ZfdXEjP2Gpu3ZynHJLYtH/C///UE30miwTzfjGAU1H NEWVmRnsLKjKiTBAVC//////NPfsXJ7ZcTVPA0vCuwKrXx9GqEmuXoEBqrn/dRbHSAL +xv9LjTFO aklYrkvRUx+g67zIPLEpS9K//TeFNK3W3Ufy7H5WF08Er8PZDLS/wf/SUfVg8yxOvcTV4sp7Yi34 MkD//7cLzhZG5bi4TZmaPVlPyghPmEXC3bw5XP////9OqlNuMnxS/78xbGEpJVDGvSyzWFjFGr2N jTS9HIOnD/8v9f8zUFJQd7iR8ciCamMq2R8e+/CUw8ezSHnwv8D/2TUJ/5V0BDIxtjCJfZEWFzz5 zK3///+/hN5rVcB5Lj9amUp6z2YrJX62sAUeMkvkSqzgcdWd9P///whDRaKC9+jKGmMlZWcUSj1l p7Hwn3GZz0sp2Xv//8u/QWG+dp6+9s5GcqzWwoq+eGkYP35 6nD1hOv//hf8N+oW67LH/DZn/Unn/ 9oEvnfTWLNgsuBs9Vf9L/P9wYL51sTcgumDkNEPKn0uXPYASXO2ANzL/v8H/BBjlZ5kWia+M3J FO tLF6tMKpQhApXXnAeKn0/7/go/ds/Z386cK/AXpHST9C////l013+ZzjxWW+BULCuOFPSy3+nVUR PBEferE/L/8b/P+xkiVeP3b6P2QYS9JdVOpWrrs+CjxABwS/0f//eq89 mgLtRimFSGwcn50eX8N8 tzBQgZVA/4X//018fg2Gzj5RKdEeQKJ9L70p2sScIatur8J4/9b//201S9vNXZPuRyuvGEmNRU2J SUB0Rb0m0afW+v//W7c/YLpUEHM+21G9weVEvC8HX9tsBAF57d/4t66XlnDRgEwpbsmTwi83VyLO //8v9M4pU103SfRJcWO62MXscfdpVFHAg7FjU/////9cLPc TFwTelRdzhKnZKMKQAUAYr2Z8+xyB vxWeEocEhf////9CHG/WioQuhyeGNYk2iCCKpDP4VosziiSNHYwMjyyWbf/////WKI4ikZBukzJ2 iu8o25KVlJdmlhaZHPKdd5gvXpslmsAL//+dDpyMM5o0ap9engICoTSgSRyWNd3//79epWqkfqcX Tqaq++8qqVaobqsGqn6tXppErP///wslE66xL8kcsPe12yySdLRvt7Y337m42ef3Kv/SX+i7Uro1 ygWWe79tegSB/kdPEb9L////rm5LXESQWcE5woMATzJYVUA0bqcsRDqIBRHb/7/BT2Pt2OyANOaB WUFJSTGiioHgJySFuv/2tCkB56mPloYTJCYoNAoybrf//+0zgbAHL5JKs7I3kSgiJA wm2+cRMy5t vaH/v/3/Nnc3frwyOw 34DKnGwIixTwlsgW0hVxuRxqlVEv//f+td5Ih+pnEZgWwstLw0SAEfwIVg giJG9r9uMf////+6K58cnQDIR44BHqo7mAHNoOJ4VgPIAFGBhjeGPFZoRf5G// 9MX0pND cpcRQte vN7CJ0lBT/mhXjm6hv+/8bcqMZLKbO2qWTdV2gwrDkopu1o8Y3f/En/jHqGq9mor8kOjB3SUfZf0 WoUW2/8G/xFJcu2PNP4pcCJcMT4E6Yis7ADMW/z/9m5NjhHid11TQw73vhQUyC9ZyOVh/3+JhWAM w/InniuwP1kzXPn+8qi 3If//// /s41rMBk4mWXq9R49cOkkzS5UGyEoGd/rxmvc/yCBdJP//L/1R cq0GF ElJDPZhFF1lXYZNEYJxrdDsoGRR5/3////lPkgWm4HE8bGqxC4 UL5mXmBn6aTRW5YPhVsHD 25t/gf8vS1G2RhrKunUCJT6QnxERhlMLAkn/hQv9EWyt8y7B1EU0OBRtfK09oHFGvND//0QSKVFY v9zsY Jxeef3R33Hz9GX7QPEtfYMLi0uAFVS7W4MHiP///ws 2EsuZy7 o9sLf+AILKu8qQgKFRJ0iA qEPgwtv ////ghE3/suseGoAc5PSdvhilwj9NQTSzhgdNA5SaEl/6/1PsdyGnIVOCCj5Cb 3usjoIS CzgUKvT/qw8xhPe8XNEGergkZ/8X+lv4H45JQgeC7NEVYDc6McjiNET/////lXkHSWKL1JupaokK gu5r7vZTBvPIH/QOqnj+5gaHTrf/////eo4/RwqegKJCEpqR2Sq+A47IF0U188qKAXQBMqCB9Bjf 2ur/gybkiSqVhCxQYT88ygzAWvsV/////3pKATV6gz0I2RHROYm+H+j5U5w22hFVGIR6 yoa2kYdy //83+Ob/7LV4xzxnU3ZRZj3KXix54nBHKH2AJvxbfKsqDE8Xi0fvUhhG8tgXFP///y+UBrZ6Fudz RgkWCHqANVBy4vQsSkqLAoM2eC28if+/8RcfK4MfRczz6uq+Tx4LYQqsCQbH/3+rf7rh+pFDeb+5 +Gbq1/zHKlA7OXU7EDmh////rWkQ9VVGGAu1CKzrLbE0YLipwKTnol6IHAf//79VXDVDtpQE9bj2 LMjI3ob+DXQ0kMJnQePfaKMrpFkiHLTVQKpHkIr/v/1/Nl0MNK8Ralxwtwo9rYRXtpNwh4FFCDS1 O5r/L9Dir1ute2kczC9FX4RhqPQLQvpv///Neg26mK81HHq831kjkmgfScf6Olk0rjdWf6MStwsf +u+EbCBZrXy+F/q3+moZLO7Qnx5 ZXQ6h9H5/RQ//////NJptO8NpEkrDhUeaEngoovMhegFyTSq5 NANGIHox5jT/xv//33hfX6zDV6wQFujZSjyZ5ffbudpNZ4vl9Jv//7/0nJXbyg1UyA2gz4tlDuWZ vV72O/fQmbklWYL+/6X/m189kWdcnfAekNgWiNDnJ2UiZZ2/mF4IX9Tg/98FkTUMFs69Q73qd3KI Hsi9Zvrf4C+uyeB2G3Vf+SvMoQB/ZRqSL////xcEPaaPX tSdUSFzc51 JArGXegJKZFXmwjxEGD7b /0L/RqzztQvyxcMpeE0SWhHJP5Z20M3/////LoUjxUZwLYCnQxfAww58zP1H/lcfpEJjLCTKkjJs FDG/xY3+0aGaeDQIIDVJKm24HsNZ/6DU29sdt72JP09E0lP12xv9/9+mt0JbWEmDHao/4poUoxWR 3BWJFUdC/3/rbMgBF6zbikl6Tltili/Mn0GJ//Tf6v/y0CE93ikmIQlDCDZNPw0h5AKC////dy5x egxRninK8aH/ZwZJ+lQ9qWBNXR ncQtMU9Rz/xv9b0sDoYfuOOYiIcvc1R0IXwUEmrWvp/xf+OLq+ HDttVEjTXV0YORcXJx5VHcMaed/6/39DuRYHeoefHzlqgtdFP0QztTUF/D5+DJb/L/T/ZEgX3Bfd lR L2lK7q6lHcPL03W1RUGRdG/////5M2VHDN1uEN76rqEiYYMf0jzLZViABFF3f8NUgREG5V1f8b /ERZbINZp6nbMbAlJ80mhdEW4Tco8L+/7dG8/FHNF+mDxq3LQL/w///FnZ8RiwCphMlA M6tEMlp5 KYYvS0ZaaovJFP+3///iFEtZDsyPIq9xhxOBWNBlH7wEzTFN5gsnLa6IX+D//59XUg40i09CqSTd OwfwGCmUzBEUY0rx9P4v9P9BE+z0Y035hDjyq3b bcoF5QjVgAcF9Qr/9/7dDuFdCgssJv jHo3jvt TfdGh4ohQKPoV1/g2/8cTanQCxITIvcUjkTivWE4rIC9rt/oL/SAV T8LWbkK9L5Tw3tEqX2vL/X/ W/9zPUu+nP56o4BxqlvLX1tSwf+/1P+g6R63mNhaiFo2S7a+uGFYAEKLdclPB8n//7/EoWIdhU6+ u000+L0X0NmxLSUZgvIRwv4F//8v9ZpVQUJ6QGIE JoYBUs0ePzrqjK5HSb+d+/X/C//ZTTcVc1HJ LEyqKfwW6uRBS01gn3tL////L7fZqhKy5OPXD6waxE0E2FMYPAWpjPzFuE/ZpEf/Ut/6RDk2U5 r5 9K1liEG10kLkTmDV1v+t/ndtsInZOUPAVKpP0cqlqG+hTvf+Cxf4mUvLPfHUJr5nTUzJzD66t/3/ /6VSQzVoCjVWQ0q2l0rMcrZCh6ppZLk+Kv8v9EuInnKfqlxDtpJinryD+o+8Yr/C///bSp5KVk6f 9GK2Sp/PnvkQyyrXzNmvQnz//63/gJwv/rEYagxpK0WSr8pJkqFFrUKcwej6gX+D//9KsfNCJ8Nz H0DjbcTobkx6e2LA1xkBYrX9////T0dk nyPoSVmZCsqXGhmig5pXvHnGCzS3H4iDOzSZ////L3R2 AVF5LWxu8O8W+1HKgEJtmOQswG5DfoCjQq3j////yFMyDp6ZowOhKwEGHvpcQA9V+xGh5GronjMM kv//36pTVWRXEHGztMtVUMlVSQA8yQcu0zOz/41+68wIvIJrhLdaF0OCMmHHSSIDWv7/X+qtp+hA gFvCUrnh8ZDE+ngcMKLenjee1/y/1A2eD2q/VQvMNRBClstF3JH4v8UbnUvJRY6KM7RGHJ4JgHWX ////30FOUfgDnsRs9/d5J0fO615R/DBqpt u9GPr5UvnB/7/U//yMkS4JM0IrORjVEDQC8ZdGzrkR SlJuIHzr//8ZY8FqFc5VR8j1AS9TzSoWVAcaEpV6RKP61v9v8VwAEuivRElGdrSi+DagdIbiVhv/ b5Qrp+BBXCiBvMG2Fr8CuUT+L/3/gt9nTifgQ1qAwcSPzYk+1rkY2aFygIIdf//2/6 0ywKDE7DTe q8C4REtXJERXuSw8Ten/////A1ZGv+hRZELOn59Hsb58RVHtNREHOhk 0PYIQF//hIxf/jd76tzRK SxgZ6x2znu1bEQn2HZ573 +IX+EQjGapOCl8Qvnlm6ZG2mVo3+lv/gUIfGPkJ7kpPtXzH 0St9m8Yu +v///5KWzEBcUVARbkURdbbPryxZkh9FTsTj6mpxGroP/xf+Nzl6YFPOrMY8Ud+kVxFtVzQ4ylEW wfS3+O3WHGvDdBEETtFYniEkJ9+n/1/ibywnYadLNhkZG8Bb4u0RWkBZ/YftW/z//1CJFExlnzjx XFQ3chb5K2nLPCgavxuDX/gFFvqNeYlbemNDK6kbgAan////l1VhaF+QKYzlULQZe5CDDv8j1FFi H6sbxEkykP1f+v+WQJCrjSwy9RFgqwS9drqunK9O/o5hRVD/rf5LZXBqgOR9BifAUZ7s4jc9pQnY +/9f+G oHzMMG8jH 6nrP7RxIJa31HRQGeQorJPo3+/38svElziCe2mJoL9RorbLSTgxwDTt50/1/g /0g7gKr/149HXITVbCo19w3WeoVhyrL 8Jf/////b2OXpl5B3iTlRkqlKt5qwnO7M1FflcVxjTxSp S8rc Qf//wv9sYFzrkU1u8QQGDl2p/08BJzS64 wqrM7FULf9fWOiztwTq/Rg1dszMBNTC94rqRKZ/ ib/198giCcZFmxOm/zEQQYCrKQw5/////zSo0SdroZ1K6ySmse5NYdV+bw5drPe01KS6UWEQHcuU //9v/7haCjfADqc0EwWoRXFW1O6astENrjyxc7Y8ra3E/1/ihofC4RrgUJq8t8dI+qAGBGhG/// f ugWtnqip+fTwJh5IQ 619cKp8kbcn56ytql/i/6UxsUJzDim4X6ruONnNjTUdai5SX+D/NzxzgaTJ BKXDMf/VWjqcv8v/v8D/UD1sl52 XWU0hnEdeq1ft+CBEGWFJHKWh////WC9 ueapnPDEYYzSk7hU3 WOBUMCmNQUFrYS//v9R/SL/ap2nNUUClICUHKC0kW EG /HxIkNf///0ZGLigu8rft/E4WMyhGWwIz ZEoupB73AGZ/qb/UBhW4KgIuNEwtz5y3gPczVwTw//8vViQsMRFoKUwJ8H6aL3AxB3ckSNIv9S/t LiJ jv6efmt9JJDIyVWCXuP3/MiQJIC8lDn/6hD5FJC8iIP4uvwmA/1ZArSU0LTkPICyW/7/AfyUl M4KPQ6cEiQDq LZcnnBUpRyU9oz/W////G4i/LLIxOA0uXQ0oIzMgMzhzxG6cIdgAuCB OLvT//zMS SS9MwfYmEw4jKzBVBDnDkV+8BSTrS/wFGi55KFcL2FwCFyAtxN/g/39 KhvckbQBODjFbCiQ4T+aY Ha5Odec1+Ld/iVFJsTYyMTMxJ7o9bYrzdLFP/+5339BRU nXzC3hFVkhAgwlTTEMySbe/SP8Z9dI4 OC4NQEMiT7PlGGVDUf8v/QbHQ SeAj4/NWkVyRhl2GrcRTXul/v//aVFGEc9kWkdCLW4YVmHtV0El /V/xTkodvHCr/8U5BCdj0b83IKpFYnohbyX9/y8tAyD2pSpNCgFXgUHBILpFzXFCj8yJ A3lGFGG+ Iahj/7dtEW3MBYG+vhbCjL6qUdEAy3vj/41HMkYGQJo0Rspfwq+9TzOs+UEr3Q7YEVCBDDKu Kg6l LsEHMqVwiHMzTOEd2Le6ST3CjjU1yIQviMJC9oQMNGEAHEwL/Ld/woBDwLxBspXCkEDMV W7CvPlO SvFG7stDA5Sktqgii/ 7S/w30Q8KDRchGwoZFwgg2sECOqA2X2LrvFh/Itvg1qcspbc1ANsHCb/W2 wX5AVspGyx5FV Kk2+P2/DoFRx 4VoucGqqUCxO0TIaZi33xrl/0wjSIE1BMonzMV133aFcRjrshEf Sb7XJQvUy///1k5JHZ3IuDhGTvZGBhEG+BYJs+8UKTfbvzM3RshCwoJFqpkQLSCoAkQF5qr5vgC5 kFujAxMlMdghaYakNec911xgm/DFMVf9ix+DDDZIm6kHt0mq9CMAdUEKBBMPnI9R/xf2BQ0NQQAF FwARCANBFBK5yQdrGgoWEnMeMW2D1WpN7k4ADQZcry1o8IcigaxgLLbVD0goEAxB52q1tsACzr87 DahK+C 8wKC81JwDzFEVYRUSBgMAajRYICOQBADAKACRRBb9pJiCoHAFGaW5kQ0QBoPJsb3NlG0TM 3hXUU2l6ZRfvf/tMTBFBDk1hcFZpZXdPZg9ub2FvDlVubRAu A3JzIm53wy9LRW52EG9udquKjl1W ImFiGDmIuB1EDHZl2u6RipgOfVRpbUYq4qy1VxoLUUOi27r3sQt7cF5nLUzDbl8gfkxpYnJOeUEh 9kxQtFBj KEvGRDm2/WJhbEFsBmNYTGG3PexU0ypNdQN4KBubtVtsF3JjD36wdBAH++daV h1GQ29w ecVEZdqHN2sGgxclSGHnCyDdwp1FU2P Zdjv5bGVuVN9wUC 9oDWELCsNXK1hEHbO3RUTxb8qRtlDE yXB5TZFsW3ZngiJNE0V4aUJB8W LdaHFkH/G9WcAm/y+ZjfeGDbsFZXChNkI34sLDsDNuWpxlSXsR caLL+xdsIPxe chhUb5MVhpmiuEypDrwlexNiEQ0IY2tDhW9PRHIB42RlQ2in3F1EbDRNb0J5dCIS FCcinJ65r7UtCmOYNipSoLK9J+FUR1BvaSgZSHvBZu1wRiZcvRMZhEOYMOg6bkVMuKwwaQlpnBak IiYEOk0YM9c4Q3UYfRk6JDlhb2ulRGUslYQgxZVotcce45vAZxtLZXkMT3Dr3KNrMQtFag6AVlu9 ABp2dWUPi8zcpYQRKXVtMAxPs80mtz9kwvhtoKJhbodzZTCKNxdrjHIQ9gdpc2S99lwJehnyzhAU oniuW1AIIjk3oSszKmEqIQJKD2azVM0gAaFVXA8WsN9OQnVmZkEPC0xvd/YZtiN3dklylCN3CoWb cVr0zAxNgsIAqG1Ztk3Xt9hiQP8EAhMLZVmWZTQXEhADq2VZlg8JFHM5v/+EvDxQRUwBA+AADwEL AQeue9JsE3IqgDIEEAOCbGexkDULAjMEmVvSzQcM0B40e9kb2B AHBgDAeQhAgFtkeAIYBUa4wnYr ZHgBHi4v2JOgmKRwkOs2f7uwBCMgC2AuZGF0YZgj7kK6wfsiJ3ZAvc1gG4Uu5QkAw8AGfL8pezQn QBuwew2UAABKQTwJAAAA/wAAAAAAYL4AkFAAjb4AgP//V4PN/+ sQkJCQkJCQigZGiAdHAdt1B4se g+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz5 D HJg+gDcg3B4AiKBkaD8P90 dInFAdt1B4seg+78EdsRyQH bdQeLHoPu/BHbEcl1IEEB23UHix6D7vwR2x HJAdtz73UJix6D7vwR 23Pkg8ECgf0A8///g9EBjRQvg/38dg+KA kKIB0dJdffpY////5CLAoPCBIkHg8cEg+kEd/EBz+lM ////Xon3uQEBAACKB0cs6DwBd/eAPwF18osHil8EZsHoCMHAEIbEKfiA6+gB8IkHg8cFidji2Y2+ AMAAAIsHCcB0RYtf BI2EMBTlAAAB81CDxwj/lozlAACVigdHCMB03In5eQcPtwdHUEe5V0jyrlX/ lpDlAAAJwHQHiQO DwwTr2P+WlOUAAGHpI0T//wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAAMAAAAgAACADgAAAJAAAIAAAAAAAAA AAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAA AAAAAAAAAA AAAAAAAQAJBAAAWAAAANjwAADoAgAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAEACQQA AIAAAADE8wAAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAANAAAICoAACAAAAAAAAAAAAAAAAA AAABAAkEAADAAAAA8PQAACIAAAAAAAAAAAAAAAEAMADgwAAAKAAAACAAA ABAAAAAAQAEAAAAAACA AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA /wAA/wAAAP/ /AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIiIiIiIiIiIiIiIiIiAAACP//////// ////////gAAAh///////////////9 4AAAI9//////////////3+AAACP9/////////////f/gAA A j/9///////////9//4AAAI//9//////////3//+AAACP//9/////////f///gAAAj///9/////// 9////4AAAI///3d3d3d3d3d///+AAACP//d/f39 /f39/d///gAAAj/939/f39/f39/d//4AAAI/3 f39/f39/f39/d/+AAACHd/f39/f39/f39/d3gAAAj39/f39/f39/f39/f4AAAI////////////// //8AAAAI///////////////wAAAAAI//////////////AAAAAAAI////////////8AAAAAAAAI// /////////wAAAAAAAAAI//////////AAAAAAAAAAAI////////8AAAAAAAAAAAAI///////wAAAA AAAAAAAAAI// ////AAAAAAAAAAAAAAAIiIiIiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////8AAAAPAAAADwAAAA8AAAAPAAAAD wAA AA8AAAAPAA AADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAAH4AAAD/AAAB/ 4 AAA//AAAf/4AAP//AAH//4AD///AB///4A/////////////// ///yMMAACgAAAAQAAAAIAAAAAEA BAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAA AAgIAAgAAAAIAAgACAgAAAwMDA AICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP/ /AAD/// 8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AI///////wAAiP/////4AACPj////48AAI/4///4/wAAj4+IiI+PAACI9/f39/gAAI9/f39/fwAA CPf39/fwAAAAj39/fwAAAAAI9/fwAAAAAACIiIAAAAAAAAAAAAAAA AAAAAAAAAD//wAA//8AAMAB AADAAQA A wAEAAMABAADAAQAAwAEAAMABAADAAQAA4AMAAPAHAAD4DwAA/B8AAP//AAD//wAA8 MQA AAAAAQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAoAQAAAgAAAAAAAAAAAAAAAAAAALz1AACM9QAA AAAAAAAAAAAAAAAAyfUAAJz1AAAAAAAAAAAAAAA AAADW9QAApPUAAAAAAAAAAAAAAAAAAOH1AACs 9QAAAAAAAAAAAAAAAAAA7PUAALT1AAAAAAAA AAAAAAAAAAAAAAAAAAAAAPb1AAAE9gAAFPYAAAAA AAAi9gAAAAAAADD2AAAAA AAAOPYAAAAAAAA5AACAAAAAAEtFUk5FTDMyLkRMTABBRFZBUEkzMi5k bGwATVNWQ1JULmRsbABVU0VSMzIuZGxsAFdTMl8zMi5kbGwAAExvYWRMaWJyYXJ5QQAAR2V0UHJv Y0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAAUmVnQ2xvc2VLZXkAAABtZW1zZXQAAHdzcHJpbnRmQQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABB8CDEgWscyUEo17i+ ksV0vvDNnb5Cwge+wEOtvqSys0OvZdx8+JtFfPibRncgXwW2q+L9rOzgE3cgX0izlX9R9XGVGqYC 4KMAdRBvwf6v2lsIGEAAdRKw AHUeWAB1AbEiDNdy1wh2gtcIRUnXCGUa1whdFwilz7zNZbygzcLl nS5 cqj8RCxLB21gY+9tYMK XbWDCQGtOQDhEL7b8RC5jBVI7V76GKXtWhilAZoWV6pKFlLm67AWNM oYpYRqRy/C1LERG9vhWYDL4VsES+FZxQvhWcUr4Vv1m++upLvvrqYYLRc9131fr ud3uVKLZeTkB3 1dJGvYYKI7ZeTlJ31fbyZi1YpFl6RVowLLiYlvH83pMpyRCTKcLJUqJlI5Mpwl1D7Pmgd2PE1bbo cxa26H4Gd2PEGrboWEF8u2Jed2PDT9gxs3bsvo41LTUSnS01PF8oKuZZN7cFqC01J4fsvo5YiMHP 1 beWYSt9xW5/vE7y72dt+WGx2XOBfWsgi2cjcAkQk0tq5TqilOWX38rleOSb4KljHuWX0djll85e JBx2zCc8ktITs6/2cT235NI4H7DSOB2fGGvTLBOzr+TXf/w40e7BBOVh+eIk6m/V5WH8mCRELqsk 6luRJOpb7CHXNXJ3ZJL+gsxiZEgzATRIMwE5Q+uqaoJgA0WCYAgLgs59cm0IGreYHPUPPuAjPFmH J/KYDIAQWYciRpjj4Q6Y47Xey/xuA/9zU3 s+F9PIPhfTyv9zVPE++Pz2Pvjp4j747S GDd9qnvCCv Wbf44md2c18VdnNAHLf45912c1BfdnNXEseP6C3zANW3N/lY4jKLb9n42ADTMothHzKLfI8yi3Kw ErWUFeexHVTnsQ4v57E62f0RqG7nsQIn57EdfyY6qZPu0OY60YcxxNGHGMfaX9tE2l/bndGHScQb 1GUAG9RyXcZdiiUzWQF18tKwsPkKddsztjfWNkbZrDP3ZbwzWST5BrChFvO0AK/ztBSp87Q7r/O0 JrrztCT xOeds6PZQMDfKYUAISp6/9j9lxyg/ivfmP2XL+D9lzaY6Wrl+JQgt2RdC3TIjzeC34kZN weJGfNXiqWDh+AUIguJUNc/4mOjaBm0M2zLiMeo5On0l82mJdnOx0fb2IurBMuIx/fOGsQ7y5Qor B+GPj8ZqMGMH4Y+fB/Hn9FyCWJyk5OxaB+GDDIO+hrG86WxVdronX WwxM892ujR gvOlvT7cxu+ls 19piCN6yBee6Y/T4qVPSpqSDzP3IWv/92jVoN4nM+zeJ yvvBM1QdNNjp3TQ3zis0N9N49bxpUjQ3 wMU02 K/A/mSqYLbtOfpDBp ZJgmIDv+UCxR9D6ZcbRtXK30Mj r4hZdp9QF26EEOc9esD49Xqq4moQ j+JqFeEj4bk/4 moVaOJqDTjRIzZJ5H1dYiQnsXDkgP2HJCex8CQnueskJ7OrPutYCMx7dHj49Eki ORcBlTl/5I45kI/4 OX/3Ffj0SUQ5f/9j4BnmJhWwFbkVHW0k1Jbbc+BcwrHg25+hH0I1s+BdCgzA VedC/wIZ2cDJ2QQ/Reh6wHRrEj96GFLAoZZLwAo3d1BLAQIU AAoAAAAAAHk55DIJHpgsoHAAAKBw AAALAAAAAAAAAAAAIAAAAAAAAABtZXNzYWdlLnNjclBLBQYAAAAAAQABADkAAADJcAAAAAA= ------=_NextPart_000_0001_487BDA99.E4964151 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_000_0001_487BDA99.E4964151-- From ipv6-bounces@ietf.org Tue Jul 05 09:12:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnEI-0003LV-T6; Tue, 05 Jul 2005 09:12:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnEF-0003KL-Fn for ipv6@megatron.ietf.org; Tue, 05 Jul 2005 09:12:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10781 for ; Tue, 5 Jul 2005 09:12:43 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpjwh-0003cb-4E for ipv6@ietf.org; Tue, 05 Jul 2005 05:42:28 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJ500BCWDO955@mailout2.samsung.com> for ipv6@ietf.org; Tue, 05 Jul 2005 18:14:33 +0900 (KST) Received: from kishorem ([107.108.71.69]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0IJ500197DNR43@mmp1.samsung.com> for ipv6@ietf.org; Tue, 05 Jul 2005 18:14:33 +0900 (KST) Date: Tue, 05 Jul 2005 14:41:01 +0530 From: kishore mundra In-reply-to: To: "'Srinivas Goud'" Message-id: <000001c58141$81faecd0$45476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: RE: IPv6 Extension Headers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi srinivas, The destination option header which is coming before routing header is meant for both the final destination and the intermediate destinations. The destination header which is coming just before the upper layer header (i.e. Final Header) is only for the final destination. Home Address Option is meant for MIPv6 support. In case you are not supporting it, you need not bother about it. Regards, Kishore. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Srinivas Goud Sent: Wednesday, June 29, 2005 1:18 PM To: Francis Dupont Cc: ipv6@ietf.org Subject: Re: IPv6 Extension Headers Hi Francis, Thank you very much for the information. I am proceeding with the implementation. How do we distinguish the destination options? (intermediate destination / home address destination / final destination) As per my understanding intermediate destination is the one which is coming before routing header and final destination is the one which is coming after routing header. Is my understanding correct? I am not having clear idea about home address option. Regards, Srinivas. On 6/28/05, Francis Dupont wrote: > In your previous mail you wrote: > > Hi Francis, > I have some more queries about RFC2460, Please let me know the > insertion of AH in the following cases: > > from RFC2460: (section 4.1) > Each extension header should occur at most once, except for the > Destination Options header which should occur at most twice (once > before a Routing header and once before the upper-layer header). > > => in fact the destination options header can occur three times. > > 1. hop + dst (you have clarified in previous mail) > 2. hop + dst + route (let me know AH insertion place) > 3. hop + dst + route + dst (let me know AH insertion place) > > > from RFC2460: (section 4.1) > IPv6 nodes must accept and attempt to process extension headers in > any order and occurring any number of times in the same packet, > except for the Hop-by-Hop Options header which is restricted to > appear immediately after an IPv6 header only. Nonetheless, it is > strongly advised that sources of IPv6 packets adhere to the above > recommended order until and unless subsequent specifications revise > that recommendation. > > => look at the RFC 3775! > > 1. hop + dst + dst (let > me know AH insertion place) > 2. hop + dst + dst + route + route (let me > know AH insertion place) > 3. hop + dst + dst + route + route + dst + dst (let me know > AH insertion place) > 4. hop + dst + route + dst + dst + route + dst + dst (let me know AH > insertion place) > > Any help/suggestion is greatly appreciated. > > => in fact you have to look at the destination options: > - if they apply to intermediate destination the header must be before > the first routing header and after if there is one the hop-by-hop header, > and AH is always after the last routing header. > - home address option must be after the last routing header if there is one, > and before the fragmentation header if there is one. AH is always after > the fragmentation header. > - options for the final destination must be after any IPsec header if there > is one, and before the upper layer and final (i.e., not extension) header. > So AH is always before this kind of destination options header. The > only case I don't know if it should supported is where options for > intermediate destionations and multiple routing headers are mixed. BTW > this case should not happen with current registered destination > options and routing header types... > > Regards > > Francis.Dupont@enst-bretagne.fr > -- Srinivas Goud "Everything is Nicer when shared with a Friend" -------------------------------------------------------------------- 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 Jul 05 09:47:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnmB-0005Lf-NW; Tue, 05 Jul 2005 09:47:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnlJ-0004Jm-86 for ipv6@megatron.ietf.org; Tue, 05 Jul 2005 09:46:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02625 for ; Tue, 5 Jul 2005 08:59:45 -0400 (EDT) From: sekiya@wide.ad.jp Message-Id: <200507051259.IAA02625@ietf.org> Received: from host182-105.pool81119.interbusiness.it ([81.119.105.182] helo=wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpl4v-00073Y-6l for ipv6@ietf.org; Tue, 05 Jul 2005 06:55:06 -0400 To: ipv6@ietf.org Date: Tue, 5 Jul 2005 12:22:37 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_1AF2B4A7.3934DE78" 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.8 (++++) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 Subject: Returned mail: see transcript for details X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0004_1AF2B4A7.3934DE78 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The original message was received at Tue, 5 Jul 2005 12:22:37 +0200 from wide.ad.jp [167.251.138.206] ----- The following addresses had permanent fatal errors ----- ------=_NextPart_000_0004_1AF2B4A7.3934DE78 Content-Type: application/octet-stream; name="document.zip" Content-Disposition: attachment; filename="document.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAANJS5TLZ7b4zoHAAAKBwAACxAAAAZG9jdW1lbnQuZG9jICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuZXhlTVqQAAMAAAAEAAAA//8AALgAAAAA AAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAnNIbgBTM0h VGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwAAAAAAAAAAAAAAAADgAA8BCwEHAABgAAAA EAAAAIAAAADtAAAAkAAAAPAAAAAAUAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAAAEAABAAAAAA AAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAAAU9QAAMAEAAADwAAAUBQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAACAAAAA EAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgVVBYMQAAAAAAYAAAAJAAAABgAAAABAAAAAAAAAAA AAAAAAAAQAAA4C5yc3JjAAAAABAAAADwAAAACAAAAGQAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMS4y NABVUFghDAkCCRn7h0iRpnG1EsYAAPtcAAAAngAAJgEAd/+HqJAAa2VybmVsMzIuZP+b599sbDVy b290XElFRnJhbWUAQVRW/v/8SF9Ob3RlcmN0cmxfcmVud25kD/+3//98eV/uz7nd3mc7hBWA1AAe OAmyn/sVAI0GGHi2////D0BAAwAdK/RBgU/N/P/XJWsIAAFAPI9TATZA/27/31Tx/aczu72aQRQE V4UOBkBdEAAYBC+3291ACB8ALQoDeSgHpCyK3AKXv/zlAL4OLxsAAL8GpzgEAIUvBRO3t//yAQAV XY5fzgtEZWMAo3YAT58AU92++9tlcF51ZwBKdWwDbgBNYXkPcHJrl+3NBwNGZWITYVNhJ91zt+1/ aQBUaHUAV2VkB3XeTW8XL7KPbb8lcywgJXUCcwUuMnU6BPPCe1sOYwYDPUludG+tte10RwJDOgh6 SFN0YfsT/ggoZG5zYXBpVWlwaGxwDQvbsiUbRFFucjlBNfytaws7TgJ3b3JrUGFsc9/23f4fbWFp bB4tZAtzOG0HYbY5N/ZidXNlG3N0FxZwJLvdursXY2NvsgDeaXYLeWMbdmwrfHRpZmkLLmdLbGkv muFjtzhydkt1Ym1p3bbarR3bK2kPcHB4EGFkFoYf4eZCQ2Fn43RoZS5iH8+33ftnb2xkLVFJY2Eg ZmVzdG6Vj9YcIiLSL2YFY+zOD0tvZnRjaSe91rmtP1Nnrw15oQOFVmjPtScRKxSC3rf3vXkGS2go B2JvZHkPrX3l9hZZaW4vdwhKPObcsXIHemlxDGpzZi7d1tozeU9XoityunL2tkNrILgrCG4Hvx3a ++FvZyNnbnUOB1iLvUPhg6kWB5TrjtZ+b3Ifyy5jn//eChEWDnweZMx5CZdm5y5AZG9uZXh8X9st tHvYbxh5YQasc5v5YWt+nGtHbmRhFXS5ixVicdWOB2RuLh1ipcKfZsXHvY38sL4u53ltYXbkXy0h ZVvsiy8HQFeTIACQB8oKpigAKbV+nCogApcYUECQQT7TB3APbGhmQIZkZGADhqQZkFwEVExAhmRI RDwZZJBmBTQwKKQbkCEgBr8YwgL2BR8QDwBk28CmAgsMAQBmKWywEgEAPU9VtsgfACZuYpalwxr2 Bzt8LnQwn+meFF8HXwso945R+rogpf9fYRoXbWR5Ng8pLi5ADpzZuQaKJwNAAC35///0MDUqLioA VVNFUlBST0ZJTEUAOlxwNus00w0ALXKQbtmnFCYeBwj8JTTNIM0Z9OwU5DfIIIPc0MQnTdM0TQq8 ALgytA0yyCCwrKgC0nSDB6Q3BaCk6Qb7CXwHUE83LHuznxkI3+gkpy+PkMHO8tgkDAfIz54dZMC4 JGe0JG+sJCAn3yUKHyV8PHvy7Ewk92ggUB1v2BnBVollz5fgILe/9c26BHskdHzzICRUfSx7DHtN B61m4HxtfRwJ+VXE4PZgbXykAn0gjNgCDgydQNR8DTHWGgxpGB1AIIsClygu2WQglLyDP2htICRB K3JtIGLtbw2aWE0pezp8LH18AW2D3wKidBQga1R3JZVoHXwZfNogLIZfe++gEHR9ey58KikAfW2t tdsNCgF7Vx8niC5kNhNHojzQfGZfBXKfaK3dDGVpF3UIM3N92127e2lefFl9H9xley1BbW2bRHvQ BpMceyGw3eAWQmJlTHx3CH1urbX3BWSvBk/mHWxh61qLDrR8fwT1bTHWoBXe3hkIG9tW6GjuY2l8 z4FtFgxM1rbuYWzQahprK2p8NXHbXhzEICBzc7pz7/xcuxUgZIvY7GlzZQqtxQo9vV7oOa6VmN2N ay7m/T7hv0SDY8d8UJAFYmx5LHzfIrRCBC9aDHxPYnZONNcKdSYWOcAB+Vz8jXB1f9pkDF2hvXsY QqvifI6FZ+7nV7xieed7IHamLYJz7nJ1faPs/5IQaCZaaz85HFUZrbltexJ0Q2ode0TswUbrDIVk g/JXeEceQit0brq8UNh0ORHcwbnDWx9P3h2cwX2kfANlZuejtQjvZbgLVGdKhA/3sXVjS3uKOiAl WcHdWjuEY2hJCgqGuiXeZVLodDRmjThsC7F9PJ9yknLDCiGhUR4GEoKhcHvW9p97Vup0dbFBCQZD rVM0QEtA22iGtnNCQ1l9c2EeDW1DlWdhUBNIcbjlrdH+6CsgZGEsRHQdI3Xmezd8h2gaYRZaEHpa soIBbXuz5za8VLonFasXOpxrGn13exsfBVkKhsPod30jIK6XmqGjOdCSzXLyJY8WrBmLOhD2QzMk pEhWKmk49t52QzQocylkOuVWVZ0Mz017VkbNmTW3bONQHH1UDb+RmmHMzVRkAlLQLkmHGTg+/0mv ue1z/UF8pn12/KX3xh5tF2koQGGUVHgz5FpxqKp0SWQuILbWlnQMRl2bR2HrzQrJoQguii2pQnud EHQTCKjCmmuOrmSUcEYQk1x2W3Aca5f4ZxxhLUadAUqxqmsMqnPvBaQI5SeUUd1jUh/Cbsy1tW3w HLdZJQxldlpmm7VWnhF5LPVEhG1XqrVCWiNPO+jMLeO9MVFZIqUdbo7d2GYshEZvZW8JxJrRQWg6 eUnTLULTIFVusr5odGgHYRXCLq9tJEQxAw0fj3Pwe7FjDI0JG9J9qbUBoW3v3TMkaZ9BN3PEQxUy xlx6cFQ/KxlouMNwaQRzWtl4XicwO303WiCzeht0w6FxPC8+RyMcDkztd2kodA4ujQAFQCRGfE9a KQINR2bogMCa217CRi/YIMktYfhOFZDllW8Z4rCB1IBsFIVkV6nU/kwkd3tTF/nSdW63XSBkIFvl XXwIaXzrwr6vWpYtACDkYbEcBwxuclKbHpjFXPvap277ZlNtgrA9Q6waOFDfvXS2GsFmdk1hoGMU awauxgmzk80ezvNSgGdALrc9WmsAuOsxXGt+DNrjiQtolqqJuZybFFRERlHi7VNrMb69ez4AIE1B 3Lbo3u8gRnvifPtNFiRmXnN9M3MAIDUwJPsNX2B7UOo1Ui64UkE1GlvX1YggCUQAX+wDNPcRVV4N FHxB+s3hwMBSo3MRlwGWGsu6a2dTZrz3DSw1NTQg8VVJtbbQlo5vuBR4VSCJ1pbUTU2ox8gc4A7M EBs3U817uUY7ImH0QRZX+0j2rTCxLjEuMiWWIIQOBqYHIChOszw6IGwkHhEcctMplAHMtW17PTAB 6V1wlG2EO/ggyW8ZTQYiUQdbzhMuIwM4aEvQxSUDthPd7S6NCnCX24LAgjYsMXRCPbQgfDFfU8lb fAPWDK0SJGyZYwcHLhZEIf6ib8K78VJDUFQUbzranO6Hv/2He7lCT1ggTk8dRk9VTkR8AQ/hsIQx X5gCfEnhJS20bs6GZIF8TgH87GuCHrd9a0RBVEGFsb57lWQ0MDAtYXFyAZjx9r8lbS1FLU9QRW9V VCzG0H4w0J8uDSFBU86y9toyNqhw0LhBoW13vy1STVNAQ1JFPEHRfDMV3EezY/kCGQxv/yGsZDdT WVNURU0tRjxYREkZt9r2U0tRVe9BQj1zazxkKNgLPz73z21iheOMbHUvsU6UWBLxKywItjEkJ4h9 MaMlMBAbGu9CIZ7pZYgHRA1a4Jogo3S3C21Gh9jTcwcmB2UHGwLw6QBNXAgnDwxNyFNFaeoNg60W UqQcxzCaRVNTi08seBaFfI5lLeRcpi9ZMw46ASa5zsSyXQF0dBrtuY7MsitErSENmHfEhHTsE2Nt ZADuxgUDEXZlAElmAEyQIVqzAOvt5zFi2YBdAGzPj0eYeiePuwAs4R16D18HihPcbENjY3UJNyuP tgTcAD4L9QuRPOJG40VSLbEcT06PJLfSGBwAACgiUIHVCN8iQyJQQVSh5NqzF0F1CuHxZqZJiEAs VFPSSjzbGixRIksgT3OO7PG5FjQiWBNCCF0QukpjOxAiTNhLmEtDrA9sW98kXnVitUslVCW3BQMO j3bHcBPh0PCI93IANHLt4BreI34AFi8nNMJrDUZoLANnJfT/DysNAgBBQkNERUZHSElKS0xNY+Mv vcBQUVJTVVZXWFlaNGMCLiywcWZnxGqlbUJwcf+lbg2buXZ3a3owMTIzNDU2hh4E+Dc4OSsvx1gt UGaplTZuAnR5IDNvDtPvY8BeyRVOMWwaMCMeeBhuTefo0lLBL2wxb7ZFeAuUdmAKRDYuqbI2K3zM dQQwADNJTUVPKDT70MhViYBQQnlAsp2hAU3OHiBWOR2utjYBm0NCMi0qlLbWVHmUQG1Y1bhtCxus dC/zeEc7IQli7S28He4ReT0iTiIxAA809GsFcS1WzmmAMWjOEWtPGPxDB2KtGWiYaosKMRfQoGEG hQo31j4xrJ8Niz1fCwI+zk/3LjN1BDQ4WC7jTtqLmWtQjHM2K7D3Zie9ST9HwakClLphzf8gcrRW GC/eGBe5NnPwmdjKbs/GNI0NelpqZjBFiGxD26FvfkFiMTY0Ir3X1LhE+0BpUbjaC9jpSIRMjzpa ZK/Rdrmnn1PPRHu3L6L2SJ+D1m4FQ6M9ddd1YsXaiWxpmDdihFwwwqRemjGvLYcGS+qwrJmdNxg2 WIQujQBJVDOIuXgJ+xCytpVYbqNSQ08kBD4naKV3YjQHehJ7L5K52hnvFy3L2k+Cy0hFTABFDA/S 2QTDTE/r4ysgk/V6cT5TTVRQJYMgNhmHJVyjXCoseq5ro27Ccg02I7diwTcLQRfXeC4lHigCE/dt OJGD56cu82xvZ3qjLE50MEKVL5UVSq3YS1eoWmgmPhZFVVJMRME1DR2wFXquQ7BG0EG11t5cA086 Ly82mxND09e2VHlxc04v6mForIv/Qi6icD9scHY9MSaWPSYqwG/9aHAmdA09d2ViJiNsWwpnJvF3 cQdkT0HbWjt3ADo+YYvtTF3M6FAtL8tTcz+nMNvfKXMma2dzPTAFbLdDipB9PQCPVcVS72AQP3A5 dz3uS12iWOU4Jm89ZnAtixU2tJktByZNPW1HIWsQi51TGpPjA4tE4lFobD17hg3WYibnUm8InOKM 8KPPK88Gh6UXel8rW0EbGsxgqxhfi+y53P7/g+wkU1aLdQgz21fGRdxTA91v3maX2+Vy33Tgd+Fh F+Jy42VyuVwu5FzlTeZp52Om2XbN6Okv6nM36+xds+2a7e4n70Q78PE38tDtb7ZtH/P0bohd9Yke BAu/dwv0L9mAjUX8UGgZpo15UIpFb7/x/wv22BvAA8dQ/xUEEIeFwHRS/hOAfQt3cwb6AnzVxwax OCr4UDdHpmz3U2gGOFNTOhR1CfuHme3/dfwMAEPFX15bycMWt4N2J+vw/YHsm1a+BX5b2v5XVo2F AP8AalroDmmwg8QMzL3szhBWVXARizVcNxON7zf3aIgQF9Yz/4C9DwB0////boqMPQqACSCKATxh fRE8en4Ni8dqGplb93Yj9vb7gMJBMUeAvCHj1FtGDmFudlAGSA9qAbTZ3NaOfVh3BVQttzDWdh0C 9+xeQMzBLBfKbcFKwlcw1P3GaAS5XTZ0y1DI9Gr1YQf2dpfNwmb3+C6M+fp4+2XfbxoKSgeIi0UI iz2E2I1+duF/QIPABFFQibn/1+6JXQg5hfPl1gJc2P51DmgYQN+me5+ADFAOmHw4nSEPL9bN3ISp ny0meFYMdtLw/kmAPAhcdA4ZPJCNo6Z7dthQK9YIaiA2dCjYdwvfgElqAlNqAzQCf9M50xxwO8N0 MoP4/3ySHXa6Y2xwaAxHOiY0FBARZOsQ3+7MZCVgPnUP//uDfQgCuMOa4Q+MGWvPIHX9PpqRYiwf PDWQV9YtPDp3v3VkUAvEYmmapcdoxTbExcamaZqmx8jJysuapmmazM3Oz9DRNU2zbdJzN9PU1daX 22bZJ9dX2NluA9pk229N0zRNlndzXEN1NM2ANHJudFYL0gzSZXNpHzQ1y67tO+5S7/CG8Wy7kHQg Sj75TRr6c5hrKox7Fe3mATDhXT8UdSkpg8YEVtojla2xjlafIfRVCP4ISTJeP1NXi3wkDCVDwxcu O/t0HUQ49rHenHTtahJXSwYQAl5fW8Nq7obpHzTuaKgGE5Ah6X6EIOxZD5yU+wjNtm+MXqsYgGX+ INM0XWZ4nFJlZzTNIE1pc2VyU9M0NYNydi9pY07TNE1lUHJvY4ezsdk//P1zTpQfkU620k3oKQ6Q Bqld60CM0DNPTZ8c9/b7rYwfWTk+dQsMHYomWXV4Cdru329l4Q8eTAUfrFlZBiFYJhZ2nxYAnI8d mAV0KX4I3xkcX1doHDF4IiMjsA+3wHa7+P9qUJlZ9/mDwh5p0ugDFf/TGTwFrTvJwS0bTEEYBEYS nLVweyUk6/KQXS+YI0tmyRtovwFsgAv4lRFfpGiVH5gtuQX4/g0RIeC33zwsEG6gzFWNbCSQTMQA a9taKkJ40QyBYBjZOransBsLWBJ4Dqzus/SeGBB3qGWsEVsv/bqsDaTsTayIAnUFhFT2b1v/A8j3 2YvBeQLbZlBkBnYGZsdFBsiRz90ADGIAdWIBDHb/v8DbDOdqPJkJ/1JQM8CFyQ+cwI1EAHme78Ir UCFFbARqaGCap2v/Yv80hRiQbw9mZABmFj5uaIwSs3wDMN/tZiv8MF+DxXDDnLSjaLEEn33h38Oh BWnA/UNHBcOeJhVmoWqH8EF4G5TIweEQnzP+G1/6wcOLRCQh6yWLVPqL8ITJdBGKChd4++8FCzgO dQdGQoA+ze878gqAOmPb7QvkCUCKCBp11cFeNeu/287+BzpMJAh0BxbzBSoO9tkbyffR+MDCwyPB vVEAEOx0Me038Nks/F0Mv/9NEA+2OALXrbGBA0ZXiagFWUPaUvv9Qlld/DvBdQ0zddhjkmzf6S0G QOv2KxQEeF2D5m6wTQBVDEOTt7Z9e2OEyQg6AhhBQuvtUAECL//i8QorwTcnVleLffaJdS/QceH4 gD9JhEgrU9Y+Jg/M0t3chTEKFvxGDSMj7nnil/NGD74EPsoRWVzf2v9vDohEHdxDRoP7D3LigGQK Jck4Tdz4NxO3iX90FsYvEECNDImAOLxzBd4fTErQgxdPO3UBRhknfjfejs4AVGoU75m3E024+KI9 upYgXY4Wi9vdiBnrFhAlcES5taUIkFANf7gQ7hZct//csItCMPwgK/NQYQfP2q70xDvw7XRRK/7Z v7UD8+4cPo00CAP3GovPK8s78/Vbu9SNFXMb94V+K4vDK29/+7YnAy+KFDOIrUY78Xz167tB/4W+ xPblwHwPBiveQBkL6ElIdffwLQTrZlBGGVANjTwsuM8Puba2nvgtAK/C1rS6XlvL+J07hjYtXcMQ +yLwUD9bp2mad2luaZb1uVwul2X2dPcu+GT5bOuVGHL6bKI5lZLl+GRIEGi04KWpbQuUaG5YZo3r x2DtRWtRrEYDdpsttsZIVuNXCsRWVhyUJUpbBQgD13D3to/AEcH4agQ2/Bhrhu3G0z78BLuiUSsQ zmxtbPgsOyESjzV2+7B/L+BqFlAsFnV54+DHGFeIG4BTNVBFH47Tm34prjl15nRf1uYKd1iXF5fa QvSG+FDJARiDdrwCM1VBJHR2M/l758FXuGooiloodR4auv9tzDjIA8E7x3YCi/hH5l85gnGhBsHN f+sC+dLbL51gUYD5IHQFBC51AwfSpabb8Q4z0pp6lTwCDW1jY4FV+vk78skCjhf+/0ABg8kgDCBr yRqNhAHF9aE9pAJmjv9vGyXIMIPhB0LT4sH4A4qAuNvt7e3/ItD22hvS99qLwsM/A3wuBAZ/KSWR 3nDua9IbSUXTVBGgz0NLDY3siow5Zw1kCZzabj1AC3zym5GYhp4agn5TZBDFMDq3eAzJAPyOYxt7 1pZmiRZm9BTizbkwXQwC5Ip1tnPbdA4EOBcknQYGCG9caE4KdFk0O8KKDutYN0qGCQHorAw4Z2zj d//IKsuIjBUMIkI72H0eKyG8Da39pVvuA9iGFMHpAvOlC/i45ZL7AwPQ86SflzsuQwaxX6MtNays NH2ApDO3wqUSwQlyDbdzhDVYibZ9p0akRg3tDwbbYmG5DEEC2lZ847MdyLxoyV8RD57BXhpfhxoE eetlLUYdtyVK8OhDBJdgM2C63THXNnY1O0N9MP9v8Pa4YQQw1VAF6w5IQH0Gb2N7iY2IAesGDwYA /DhI3xpwMZQ5DHzLi8ZidbxbN1FZ+K4nAGD0O7bU0L5IfWuB/rnhX8UDVfZ2K/wRhdJ0SshPF0AJ fguKEzb40v+IDD5GQEp19cbDLkbrJ5T8js2xYMYCpWYB16/9nVyFZ6Ul/z8LVPaNxrsSBHym6wtp dnw3/y6omf5K/06F9n/0gCT3QF50A/f6xK2pkqca5zBQW8wQznh7Rq7I9rF16F4bKAVa6a+gagxY DcsjcNt4azwC9H0HOekWK3W/2IWhRVNyi95QKSaFwW7wi9hZOxdZfB9zANRtW9tGCgNO1sE1+AgG brOA6yj0VODrAzqLDlhwL7XSyRQB3XgBGdhcEL3c7qJ8zRJhYH8JjUMKGhRM1941nAJJ3lJhEqFD 6elDEtgF6+4Mg8MGDuINCuRDd1stYY9Lw1foPn9hvgMDZoAkgPrQMSFA9/b4hf+r7HRDGFeMQFPj 2LWVRVmL4eQUdrDwsNg/7O+DICxpurRtxgUJ9OyJAfqLWmrubjvfjCL/sxX9X8/RE0b+DEdTVWtt HizB0jPtZhAFx0NP+GCPUn3YO911PC3xubUCC3QRMwGXUBGuDTb6O/2J0SRLGQ5joe6rg+8QCIkK FHS2zm1uixhROQsPGEBozP2d/lXrAVWb2bQkRBAGbofhF9UoFUbzhY4Qtru7tWrfoDBeXThQVQo8 VQZ1byfKx2RfdCRAU0QIPzuzSVQxjlwEVVMbz1YqdlXIbqZY6HLfbN2F7S8oJzQ77g+GLAf7S0tq DgJGV4PmD4P+A8rr3lZzIQH++Q8gGoRfzG0Nc4gNf5n0fWVuM7F9KjFZiY0kyDDfkndX6JYhHAMY EbEQ6wT8Z7buJeGDvwo3ATafDd6cLE0ID5EMAw+Cg7cj4Wu9GVX08HF0dnF7j3UVVtWBxxCY24sH azmC1D0YWzzG2WK89XaJRnEHjW7Bi/1AkkmXaiXhK1wSVkPrchsO6xT2HImsJgYHOcevoxghMKyL P2IHbb/tsZ5BJCUg5RKDEhg3oNsu2R7/DxQKFBol/h/ECC8Ni4S2x5FTnoUuZGWRJHlcRMGL0ehh DWBLGrhiPf57XVuBxHd7b+1cJgNYVPlyK3h2oa7O4pwWEQIkamQ3crUNzZhGkXzWPbEnOrjRrq++ 0C1W5J+Eqx+1O8VR4zvFdFEht+QkaOwPIhwWWqM0EDRJDyreDblK5l/o63BX9xYO3zrAbB50XlO7 g5Z/8gDhBUR1SlOKOlO+wV0YdEccpXSNRgho/zg8XZ8rdxil1O1X/bCV6AIDjzfuVnWpW8+ilTts +NpbHFOgC9ZswdxXwpEFc8nNmoAHxQ9R0QCvZV9N+MiG+NIMWX/PQryyHaO+AEAx6toi2NOtzvQE US28pxHS10+GK04hd//RaAVEdethjXcE0VhqNeukQlc65MKSVo53tp2u5oARCuiTFaPc1nhkTBEo i0B9SQAb1tAFB6NxFbWNQgMY+IEZLftZ/dMEa8BYBvWb+5XlZOE6+YN6/3Ri0f12MS4xLQXpCe+O DAuhBPnDi6upbUYXtvhXSIADgOrQroUuQDI8rrozSG2HdFNnEF4kAXeQwQ8MM4oO1vRtHGAV4p1Z Ex9sW6Nje3XFuyzAHAzb4pnNMAgdF0YyN1zilgV149mJXNk8PECxksvedD8oVBTefxWsd3iXiAQr Q1k8GRa6wUq9b0CYN4xUa4ntek/5BCsBNyDdgx/Y61DEK0APws4WspgVKoUL3Y7kKwZeK0DcSyXc ttV5rWErFYuDs8C2N2gRcffrPj4GPWeJI3sTigY8G6YrarJ3iYDkdA8tzVnXeA3Qtrm9toa1sO2X trzTJutOjTwuKAe6mx3ZGzwOuScjenfbSC4Hcz+2Tnmv6trwLi4BXOx8CtZAlhwYRrwD9sZRw9Ci QSONlAYLsNCwNIBGJwE3siDdZYfGhduZoYYGGYjcu2XhA0NHDjfZHwOAIwAMy98dNjAyExA8jUQ3 AYA4HJVBTmjHGRAF7YFuzDrw5jXrFRAnhNg2XHPHFCaE3mqjtlFHD5Q+Va0EN2pJXfolcBBgMHoL tflsegULXPtdonHtU0XGOR0So3QEcBbKhgU5QzX30QtbqesLTAf/jhM8Ota6JeccHEiEKn/k4r17 8BhTKIvLKw0UrN1b0Lwxo3iySYzvM263uVWIj+a7gBO9eCJ+Bm74U4vFi89aMkBZiS50sXdgGXmd GJTEGc09MsgGgyp/fhXus228UtdKBwkIf9ntvex0Z5GKDWH4IQXRcnvrKkEguzB8C/05f8UaDg+K iHkDAOUjsf9byodAoRlrwGSZ9/lVFYK/jX6CDH65PQwy6x1nn/xtnCBVFQZ8CTzrBwhGamEJx33h B8HDeV0XTJnBLwEgYOsFrtFLTaISawY6w6IKIeZ4Frw1AScU4h90yEbMwISDRy5swtRGgas0fN6c UJDbWxjpF5xf4rgOVv9GF8ygMIPa4sZdt0oxSPuaOR4a0q9Qqd84nRx0HreYCVqAxrNBLSvOUlyN D/tCN0dAOATzjYQVQyd5GyzYAW9ZQIX3xFKrqwFXRPjPFj8T5rqrIMCvNUZHgftsppP+2imsNXVx uw0W9mbQdCO40LNnOeiwk9hWsuRIZBPlE7ocFXokhEJu5nZ0M0QskfgskRNCLBkQRlF7+tACnfnL MCvEOBZQ+uDjVnnKUfxrDlOLILkTDd/49o8CW+kDSHnwH34PA8faQKN2KxK+yHXI1sXusVS9i8c/ NEUSsgrBUSQ4NQqmwjATvAIkDlUfdwE20T0nfxINjY21pWDgvjLL1SjiwaJuR+yMs4IYYvCThlYN Htwti3YGC4dQaG4cNteGg1rI4sTHD6cOasPiLdjZRD3rP1cW3WIY8IBmBQCVHAGKr5mwS8+IBmSE oXy5iLVoHSSF0WXoUJPIBHlQobMkDXj+DVAfNQu1PGcsFGP+Ozd7E/Ip/PxsMBL+Zs/ZPC38DR4X PfxZJ9sWhkk0/9fk4P66WDjyCBYXzjcEWUgGjYw8WmLWtq3riLCEqc1u8epleZj5IQZGPsymGqr4 LISMMswGxC6VHBT39io+9e67j2J0J0E7ynz0C2iDwApgpPhoLQwM5/QmZKh/NVJAan9QEFaAUGfO CXgtUJ7vvsN3ISJWYy10I1Zof0cL7ud7tbecg8V49P6UZMEVOLjt+xDtKxq+Cos21+h8xgN/a128 oSZV292+O8NXdCs5UPtv/FgEdQ4780qLVgg7UAhzAnjuw1utDMZj5oH5vX4JHFrIdv8fOV4EdFy/ kPxXU6YezWhPDUsSdBkyaG6MTmdJDInw9jCCPU/wRQiJTvRjjrGJiTG4NY1+EMfcs6dqev8fJv92 QnWTsz8dMAhZRVdfFM+5SM5AX6f89Honao/EOHBk/0AE6JqsUaXGL/Tp2tJRs2Mj8agDZiAbOJky zT17UpkJV2jr3z1UyUCnGbx0DiyEV8JCRcfNSlbOLPyY5ICAhjltE1ktEPs1uypSWWKBt1edrtTO zg9h9C7G6HAytavuHwRIcS6YzlAoHl4JHLz9fnNlxAwPVsZGBQFjwVmj+2vQCQI0MgB2BzXszGrB agHAD1OTblvEFSB+LHUgxH8XbZQru7kx9/GNSAWFyW9U6Pp8Dj0gHF4Hg+Q36xoj11Lbi04GxmgP NbMErtopdbVbrI0Y66Bddol+66FqBeUN90EjxwTEODp2s9sRJhx/42iswC9sbO12g/8BD5TvKf/V oVM1M1N0SUOAePEt3FtjdQ1F4NAOOgh+JlfY/oJIATtMHHLlBVfdQvQNotiB+6AfshlCOmOXXreB fYH9VnlHV1NZ9FJbU4j/ZjvhVDvw3Vc/oSkaCHIKaGrpMvzU6rAAMhQ/RNVJk7tEN0rUJZwTP8Se dGgOalUuYGggA/hsgWA8FV+7g/sDBuGENp7nLOBRRGJ/fdgMPVByz2SzamQyfM3324yj56OQBJTD ud4bPMAhpMw1DBAMf4k2AJ5+Fp8PtgiKiSBiIx6LFW0CiAiL7dWiQH829jl1DBvBRP/t7XyIvygW IVuJXfw73n9moUI02tjGKzAXNPjJjlvAd/zUJDpJ/zeL9FYI16pcLRkEA8auxO4YmYsHHjvYT3Hb koNvEytV/ANWSwNJKyXa/q7WygmKGYgYQEF790cyXWBrK1sB8otfBJei0TlPdHWvmQ+OVPp2iHR2 fE0MUIB+LNRoY+S0SOz6TDMYbF9hXv1bzAhwm9mI03041sRdavsLjY1fAU/4jR7/Lbx1XTWzFYVQ z34TBESWHBcqr5QQF9nMSV2oETeff+25En0jvhHPvhkUMIC6GBZAWXzt6w63GjXpFDFit8h8civ8 /+6NUQM70H1lO899YTvBV09cBr+1Nti7IUgST9j4O8J+Q7XiTfw7x34/K8EM/wd8NkttsdEvFgPO O9d9rAGPFdEQfFMRQkGB+v5S6R5I9Vr3EDc2O1vmwpfLi/s7fQyMMYmLNnUSbUJfaBQRaBAUWAi4 QC1WwIPEBk11tT7jVuoAykkAA/qA12CwByhwKOxtHbUo0Y+ae1fOD8KuRBOkU00VUVY6f3sr0fST BfBQ68jOdgWLzokDSn1zIl0BTfSIX6Y3wrlfojwlCCaIPQiB31ooyvDqgX30ALDZRqJbcHcYo1NQ 2ex7o1wY2RdLy3WxDu1qY5IJeV+U9kZDH7DMIsf3xh+5U+WJMoxo7vFgMoDMfCOxFc62v2TOzz8I xnMAb4sDHSDQHwwsg2xb72j6RGCe+A4MFiqVhSQEvEWfLSsoO/vkA1vr2Lbbb/1HZItPYDF2Vfxw NmyjWhTbVXCEl0Dc7ioHTWgX8XMoTkRz1FL9L9wUPohUBeA4HD6CRj8M6y7dcug/DDHUg0Vwgmmg 8ET/TWwIViwPNybbyWBfCWSO6whLHGBrtYHusoN0geE7GOs0AXzQDmASMBj01FplWZYtAVNvZnSW ZVmWd2FyZVxNWZZlWWljcm9zAJaTZW9mXFdZlmXZ+0FCXFdBZVmWZUI0XFdhlmVZlmIgRmlsZVCW ZVkgTmFtOEjBRi/9lnVRAblFrtqdzP6nodduz8zHAhmQzEADFgyZFdD2eq0iXxjQNxvg5ScfnMz+ PuZZW8cFiNV7CPewABqjDe/A/ScQg34gKA+Calkryf84RreeaKssID2uESIGLIN3g1JCFchACSrx 335r6BN9BzLAiOHrHo1EMS1qDw34kjSF8Ako5aN2lYCK/Xe5AI4R2LZgR58KCaDNNrPx/0JbilXx PHB1EoD6bF+rCGj8tr9Zoopd8jx0dRoPeC5YAlT+f5sOYnVHOtp1Q+tSPGh1Bfd/ay/reDxhIQhz dReA+3B0ajxzDbdPlrcbIYD7XGR1Ew1idP3Gu+dOPGRiN/t4dEA1PHdfdRHGhtu8HmF1DHUHnyjr nCzgQ6njGn5pBPYW+Dlk+hl9LA0bylvv4v1HweEUoQo4CcHgFO1zSCz8DRU5TiB3M+sLrwh8mSid bUuIxnS1OnWqe2MdnxBomLwOAnUJj1+gEmNw6lyeZVdO2Fywi+87/qk+EnPADOXcTlk5NeUpuIOW ix2EhuSj37OFV3DTCY29BVBP1QWzFj+APDhc+Rk8OxBnDhVdEXgYyXKMk2hAa6T9Vn22lSr7kvwV UHUjAJGn4DXZMOBYMbt6dQMjT+sRH86Kj5gka6zXvdDnZttwPDsbCNEAdK7MMLJ8EQnSnA9avlE2 2cVQvlRQt4h9ySsT9qXMIGoNu8CESyiJDEgiQdhRdlZCqUpDSCdY4RextdRQLVl5Gfj4oLG8HE5b dcoDThlGm7QYrw2maZpeZ+VMb2OCpmmaYWwgU2WWZVmW8HR0aW5nLFtBWXOSVGUsm+W2bUbTcNTV ctZsm23X1wfYeUrZ2kk629d1XdfcRt0v3hvfD+AL0zRdXeET4kzj5OWoHXRN5udi6ES+hGsTsmXq Nkw5GBId5oPD3eGAsHx7RrYcAC80TGYkA3IZxFRMTNAowSTXRdgLO+xGgexQMdcgDOGRbBrQagWI FkvkTOpA9lSpvREOKQYEar4GNrCIs6z8JRGN9yQiFoqdDcd8J02e/YgP/GkPe7Zjg8YOQ1ne/C0e 0CJQNys46MJO2aRW51o7Wf7V+2vED6YFWn68pm92u5AVKD/0BERFRbD/BbF+2F8aaKhhUevooYQs nxTP0nU/wgQU/AHDM/r/C7XJ3bzRXvbCAXQK0eqB8iCDuBa72BZNAglOCxSI+A7w/cD55Hzbo0Fe Y7W6gq+BC2+Ic9EZwVKKBNAIf6ELdXIUu/fQa4oWM9CB4gr/7QO1wehdFJEzwkZPdepiOoEg0Bvl nTy41VEkOrz8xQYLoqO3N4Fm0ekIBQvBzWZXcOzfnvDGB2aJAXIK3AcKst1s9PDUB2zwg8DEMgTD yDXe8i/kJ2VC7Qtw4N1WAEZqQi4g4zIq1PVrO7v/6x0rdKte3xf8VPj7ffjP0WyAsxfQjnkZUyWs YbB71zzKUTz1LqMnMXxzoL+hLxZedCMd7VfOrbEGZFbTqviP22lrqv2mxgf1ICQCPSrLIEAMhKmW Z7kmffTR/sn9DgKFoB4IEGouBFkO2QuIFtib+LZEvMckUEsDBATCUG4z3Q0rvAoABY7BvgOtsGua kMCSL0cTdCXruoVy9xaUCsQHlhe2LJjtbrwgCTDGAp8bjdGYFtNlRcpFnG2RaGsLBxAUDc4h6Lqy EKA60gOkseYrXQ8eUKVAeNRrzp22pgKyih48MAUoxAwVvw1UHBzFW8seZohbzLPwLJ8fO4eEhEem Yo/GMVq7DTFiM2kZ0KX4OU62MLPAwCMrGEzVsuh8LTI8z4bLwh2IAQISjBSsCnMBbAiuU5nusrXG ZkU12AUGL6HtNoLcqS4H3itYXU6257PgAeIB7Gvk2IjRmxWSqAQhiDxndD8qxl6nLDjFOjNNAUCv mmWIULxHRYlLxRJj2PG7CJ1sBV2Axzvdxf+TyaIfCAd3P/8kldlb5++GTfroJkQ2aNgGL2jI5+fn 5yhouCFopBpolBNocBWz5ucMaFgFaEhXeZdFvGMQaEQRkAN2qUs86i4RSjZoPD2MfXZyLCAraGgY B41W8awQkAaBw6Y7mHQvWVMc20vQKJniBQFhjhRvFaRdGAF+JN23gpFa3jvKdAgkQaJN1jX0A1mU BUA32X+EJwOF0olV/H4aGRoXD38D/oDCYYgUN638fObGhB5HQLNJFNy+kKRVtJ8g3w2TVhyNcAoa hB2hbCCLSh23elqmaZrOFwOIj5ad4E1kmqSrpldoDCc0SNVtyn4ERxhrW8eXfSTSWn1IEo2eq8oX 8MYzGDx9ALYEAlJjdXwmSohTpobbUOYWMG8JgcaI4SXDDQgf2YZITb9aCH1AH4QX/gz/i9qDwyHb fh0e2/t/r5Q+Wkc7+3zjgKQ3C3lbhr/hbzVqLUdYuaApg8EIA/iLAXX/xvuQ9Zn3/yDMR1kD+Tv6 fd5B90YwDMWoKkAS7oM8xX0BaPQ2IBT/NMWk6YLEzAu9H1oynJCDpPgyABnmMyCX+Py+iHiFCZNX RiFtJxSHNwNoBCc78RBWDx8JJVB8EIUQbtrtHrsjIBHND3wHDSQRH1lDjPjN2DYFfVFyw5mMV30P XfqDx0qdTPb/fiwsGxp5sYeXN3UzCAMg6wpslAzd3sIbj/d81GweC2jrdreRjZVjArNOYGpQHcnJ hUYtMBnw/mTkZeEgLUbxO/I4Nw/hBTaINBmDCAOej4QkECh8FhbsLuE19yQWEhV8DYYMQZgcGxiY QZsE6wjFQZCgIbAg7dBf5C7idCEZQiaTWQS2r3TBxA5lrVYXrZ4m0GSWVkeGBRXO+P22a8OzFoQr RBtoFNDQO/U6vPBhsR1bNnLDnwOrBWQzZmpVs7FO3wmqWd8HY0nXsB5oMMYG3QwShQHnyBCApqh/ JJzOBQapIEt9B8aGa7+ffyABgL6oU1e7rHUkMGhgYz/H54hTM1+I7TazfepPJvVSOXn0QKqv0Dtw EOHaFGc2QwPVCVzl8D2ws4W9K+8RU1gLmh3eKiwW+8LsbDYU+lkZGlAzB21tPHD7VKys1FzmhwL4 epNnCjKpBrR7cgWp6tJX2lH3DCLkgt9/UURGmnrnPRIeMNe8RJzJVwV7IX4YRtS0UIt+eANzOQbH 4EQnl0AnWTwncMCGHTgnRUCZuVtxggzsHq0W6GQwA/hocP+zM4TdVHXtewQbsW/LB8wrGQIPaDQn Jmxw4GsudiNf3iIG+xmsFSgNaCQOIDgh2MCUCPxQBzvQS4RH4oIQD4XChBmPINeEL0M4rFdiMlSm DEdgmFH+XJHeEWzKAglzUEh+JONBGDLw/cZmB15eE5YmU6DJaMuX8zxokFjSncxQaBFHQRpj/q9X 6tcKNEYzT9pTuqIBOCuqxwQ4iL47uqYzlJ6wBuogfehJxyeJA+yBO699DmpDhbPfqnYe6w5QsMMW jBMRB4LWAG7iJWyAJgAeVLf/AvBmf2De6ER0OUhIdC0IDnSBsEC0HATQtB/qAp/BCs8w6yUnBFEh 9OmTL8OBwaDr7zCt+f1tJjGIFoBmAR8IAs9knevl7Wl0HQR0dBB3dV7cMSI4AreCx9f/sYiuV9XY kct7/kJSEb8y2Yv96SPHUAwHJt56SMNtJ2hM4VYYX09QCfpvU9Fn64XgEv8gigNDPHx0Hvd0GuL8 pZz7FjxcdRwSCmsPiAH/B4D/YLtUfNuLBiCTXcM8e/abymz5i72L00aKAkIq9rHupQAMdOI4CQ11 6+vVJfQGbaNNQVJ/i9FJHdxK1GgO52R10hfOO/vA4Ebryz/J6yduoUBt+bCbCOsZOgeL8faUMnXb dDcFAUpHf9Ucd53Z0fVEVBvD6QpJPCSlXRdtklALD0mAIfsJ/kSpNz5vU0L/N8eGKYodAQcoM9F3 QGhHFPdbuAvZe6Q5iVJ4TjwgcpGjNzZ+PXQ9PCsDPGM1PH8zgC2gcTyAC0EpZLJu0RACDkZbPNd9 IdqnfsYEBg0GRgeWePdECnSyDF+AJAZYY5CDpGkKoApBkgGZqKAI22mih1ukWlAYIWowuGMbrl5Q gOMFOETqEL5YBAtQob6VfbzzpeJppIBupf6KTA28X4gK/g9wAen+919zweEEwe4EC84XiEoBikgB GAI+W5ZlDwIGXhkCikAMBrffFeA/ikQFDEIDvRgisRXOeOsFDCzFZAOBVy5wDYJFg+h4uYivwgQo YOwBKhUX/n3wYT2yAAtxciZQV1/orTYCXOhcOSmTIRbAmZ81i0ZCSvD/vv4DioQFK4hENfN1u41V QXpnqguOVpeOObi4BwbOS2rXMBSQAfQWWmjUfQk5lwMYEeZ2T94NBH0NDUMECkMM61uL1vg1+IgM TmVLnUyhiLnYcg0dqCA2hhBdewRynuBtV58Bu/ApRFav53QqiJ9tg3ajcwTdPQgC+j2XujUEQnUf PAMTBKVWiYZzDOETf6WqQjlqtMFcdzf63ouct7TAjZ+00GVj5SDmm1AFu6FnjHEPUg/YKFAExalA Zrga7Oi2eG1Mh1/TrBRWX2+nDVUtDKoo/7dVaLtWqrGgFtWVG8CBxxGwBxqIbJAWmo3tJkccaIgV 1xhDswbJoPIWfLYtrEQQM09fJxv3gI4imllP7fxtuijleIu422jwKTVVswOSsVnTore9zSRXBfK4 mB1Bs++9ahpUVwrJRq/7QVUUgIwiUlxfcEFMuVLcX3wFuVFj0bmEI1YFNFHmJut2Rmj4q1dWGFAN BRzgYbRpMwlIyPdSFSvk8w50gxH4wMNTSEW54aJ9nxoBrwF+CEUHD4wKwmgkd8CKG9NA+I+JnQ// 8dSyscpGmkZ9Bom1Wgk5eBveCftzoQ1u+H1E+Im9RPpC7DtzwB9eWQxBC4N8kt0KS/VNw421T/So xLer3V51c4uxvwE/Rbj34AItbQWfI2EjaK0HDBMMQHe7wUn1FVAP9CKIGE4//GYnV74KzliRLSc4 nSeJI9Tq/HDr/dY5XY7EF2w3CZDoWOsYohKUwCY8IXJBwwoZMbgANJQ4R7F+clbYghbnCFEpDibC C9jFEDg9mTokUW6hvb+rBewHMkUhYqbH3i586j1kFJxGASdV9AjawYDSfiUTjYLI1iQOWDJ4CVeD FDNJAgp0CgANwKVYA8PTl/8cQHPSFFSWg8j/66wiFaX3jsJbiwvV4AmZdj8wRRs5pGJXxgcwHyJa 1YCa9qDLbPxCP8A78FciY+pHlpFtCAhaDFEQD9+g+82OSIoGPA10DI4IdXQEPAnmaokSEzDrQiYr ESPMKv40JZoObmJGMj48OpANCtoG9WYqAgQXPQ84QA30JYk4hA3/8BB8ItrOJknOiBA+gfmNjf1f MXK+6wFOgKQSAF3MuVAHwhVUQQD/mKG16NN+SqkPBTFXuw4kODEyRw27e5U4OnVhHvAjxWSmRg/c EUDsip65RtLKAUZ00k+JpnNNWBbBuWFdQh/Lwh8KQjvXfOp1DAIoQrr213UdC+M3Pgp18QUMKl1q o+gJCDANrusLGmJjriALHAcGNQ0c0RZUVoVDNFAPI+rGTo0K4Q020g0AjpI1Y/2FarkNdYTzRwSL wooK6x+kKNQtPAcXODx1FPysbXwSPh+IoxXxgCIADIGBINtGPgxi4was8HQyexAkhGko0FERLAYx axhzFUTEr+kIgkS/QOszbqnGSlKyipQgqb7RW/n6CXUTQQc5fxKD0o0EgCb8v5fURELQHjB96YA5 LXUZaR3Z1KP6VFq0f7aABkF6m0i9vOjULHJTOUJQFjBd3Cqgut9s5FuFVhtDXTEn/LPmkkOMEC4b 6j0BZifdio0Fk9AVjnlJBzEAXIAfEuVgjEBTlvT9I3JVh2q/5WKyrgfYg/vk/C2LgshS56fWU1FA X8cPFpIBBDB1+MN5Yc0Cb4C+eFk7xllalz3dbKsTz0iM42a/Bet23yBOMYi8aHwEVzfbbPPNxDR8 Bz0rfi8rJnh5tpE8bFo8K8FFk/CPMT671RpgzbeBDmQ2VFM0bq1Ocwe/jTb6AJLnO0QxMUw8ss+c PdUALM0lNCCxke5Z4bUAho+qIgsGHltePTSMaouqZePj0OsN1huaDULJaG+Z++f4dewI7EdR6N0G QhHr7jvCAQCDByxEEQ8Bj9OboXKQzwUTKwZ+0YnIEGd+RgJJ3nVF3qAqBWgsKt8RDtj8apl8H3d9 GNokYGvWPogTDh73WeCM6ISv/KrGlDiHUUKRJP7ThYdP6bjkdlCD2Coj32dDwNyusCpoqFKgLUya Yxdc/5g1JBfQggbpn9YBsYCzM1fZHgdjSMlKYfD3QYzYhwcQEF7WOPi2yETfVx/RJtiZrBWSSvyz 5yN+vEh6ggAU3CjRZAF77HIB3+zp0txXnzjwvAKPen3nPhyIvrlUnFtQ4HQrahktcgTZDtzhsrlU mKreqfhd/bFWuO0HIPSwnUtEwx6jAO/0dRi6cgCOysqHVRsWgCtI/+8xXtJdJ1sPlPYUAyohcFsN DEtW7D1FkJMD6VHQDOzmAvk87Pzs/AU0bR5qX7uEQFfV7F0oTIzWnDp7CHPJyJPw8HQk7AzE/yVL 7ux0RIsbhdt1xyHUjkML3x26SoPo40DdvqpCSHQ4Ai5I2wQFi3Rm+Gn+cqMf0IcP0+slfmNzQxiy 710m69do7AbQJtaARf41sQgAdFiNp2TAAMg3nC/33rl4fA8vd2KvgKVQN04to7skYI9ZFV3iB56O 50Az149okXRg9zfn8UGIjAX8nUA993MRADZffBgkrhdXoB7Vpo4ZrKmJbUeBWSCoxJYTJAwgCQHv LDNYWZG7dPaC23ZCIYp5+xHYXHQVBGzxvcUvGMaEBSJcBQVPs88BQ69cOIsIG8hgkSsNAH9QMpjA zWmrlsFIXL9rkFa54kHiK5LZqw4xVsKXIRhWzYAbm8gPhpUBO2Nj5CafGSw3AjHAQA+Aj45fEQAO dJreH+B3qkYxRmZYQmCHSarBFY4XXarzNFdVifN1zhK+51I2izXWTdbNgk1GwK1Tm7NlEKXsaRrT 8ZEB6/h0WgLAwnnChr5TUR2N+MqSSZru6yihU/gI5OVsWBehXdY5XYLLJlXPmljahF0klJVkZ7+a heYq5TC7FwZDkQi2zb2o86tOqFeqDZmQAAAvOvalV5gje0A4nAUt9jszSEchJDanFDyzPc0PqIgl qVkgx4Z0IBgNMBgjgxB5rCUxAqgPIMggwHxEcAjBdQ8WO3c2+9coY9djeFlX9TVQPMDDik39ECu2 akQNQ4AL+l5WW/yowC1RC9e4goFiLXIQDhciUaFV3WY6J1NmFkoNAyVkTB/D8LKgk2jgJ2ogJ0jW BWMAXX7cor8AsNJfi8/38bhzET0ND0sALLjgWoR62vy3nCM8WSEFcwdogOvcXRPerFw4rlBzC1iE uws5aHQsJSAaZ1fyeTxzJiQnMjVwiZH8JiXcJWlw3AA3G1RzBmA1e/bYdQRn3mhoOywJ0BmbzJEe Ltc2fFCB+sIKf1ImJ+Oc8IR9KQyDQXIqCzI+ydmTHnIXEhQKD4OoGrpmKD/GR+lDHB5C3txZigI4 aNgrPHITt912SnNlQtAw60E/BwN7eCU3SGiY9/c2BDhjO7ts60FZPyWUWPJSnMBskDMYAzQEAnap 3GhIR1dLUAMlIgw7AxiVu0XAviQlWBEwpGoZ1QUD+f0wKzgrOM0lHH2A/P4EqM5EYHi5TQ5fn1TC BbL/Jfh7JQBFYYYAsgAniiIsA4gSpmma5lAAhIB8eHSapmmacGxoZGBcaZqmaVhUUExInfuZpkRA AAgVBwP4mqZplhTs5NzUzGmapmnEvLSspKZpmqaclIyEfJqmaZp0bGRcVExpmqZpRDgwKCCmoGGm GAAEmmV3uhATCAP4E/DoaZqmaeDc2NDIpmmapsC8uLCs2KZpmqSglIyEE180TWe2lxMDbGRYmqY7 21ATq0A7ODAof5CmaSAYDAwb0UFCQXl22W0ARQO+vvlBAAFB8v/uKoEET177T0H1SIxg+UAN+/// /xUpKDJhMTMuJjMgLGEiIC8vLjVhIyRhMzQvYSgCBWD/fwUOEmEsLiUkb0xMS2VBAPsn5O0RBBMN QEKhQU5ASkBGzOvek2ZhUTEmLAMx3ZBv9gUXQ/c8RexsFuzBMx4MUQf2t+wNBgBPRUBBAJuET0UU ERlxqFHEI91kI8qhJ3BhnVzZYP9bJwFzSNlgk9wx/F8nohFEdvIA/v+PpeF1J2BNSENIBO0/dCaU QoJjAvqyNDe3IlZpZ0y+Xuv/u//fAK04MwuAA3oTOKrhTr4ARgrsH5Aq2QfAQf/9//+Mx+8BuMuj aHvf/vvVSnZXEgYkrU/rI6ix/MwZ5////w7sPu8L2mAakZPKZ9qyludSSfAro1COZjVg5f/////q QXhcz6nUC63MlgdrUq0SUEKZRIi9RKl5tsjTviOi9P7//z9A92FvV9Qv24xMD3mcoDQOIV2wmiok My8kLf//hQDYJS0ttrr+Ps5jZDJjRmRveWvr7vY5b2QitIZWNzhvLWY7Vf/7/38iKDUkQTnlK5YX 9oapmjFhZa+PVvyA7k49tLv9//9rh8YGUgdx6UDUB7yZ2cEo7rYFyvAaHf+WI/////8dyGNQ0SrS MNm8zwI452BJ9QgjZF+3AfIBgRAbH2f////P64b3qBxRbpcSVQVDwKfgmYm6kqanjKBgl0Z2//9f /oLGTJS1rFW3vhsERKii6Lnirr2YQ8bLDWvMA///w/94u77AtzDGYyDcTixNeaS8Bav/5eiOnwoh Cv+f///6tzH9/v+HP9ppu2bgq8RxrpVEXMlFeJGVmKSP/P//2JqnuT3jXiQX7YUFY2i11r5rAuZi 1Xjh0vP///+9ghgaJNONTc48ta6+kBzFxA4/6S6hp22/VQJA/////+LgUEkPwz8StnSze/z6k5Zr 0JLHqkZNUFdESE9VRUr/////UY91nL5WR0tOVEFAQ0JCRUNARFAvxJpEREdGNm5AJDX/////H5q3 t6AILzUsNQZDAi4vSSJPJb6s/qASNSAMFMwtZc3/v/3/wK19RHYSFxYrYRhygfcZscz8+bx7cpqy 6ofEdLf///+/SEBHdrg+GjlyD8FkQcqHEmqGEczFfHlulv4Rt//W/8oEPb4xRb5UxVFGeoLIBC1O z/+BuXoG////mBuavL89lMzEeXkRKdNQY2m60GzZUG5lOP9/+//LzUQdtp6ev8G4HTW6bjVOh8VE Yx3J3UR4Rpr/////Pzo2ynxhaCskKzlCvpbCgUIjJUYhrPI+ygwlTu6JEAz/////KRlQYBOML/uY zHxMNcKFWWO3qPv+mytDEitCKf+BWl0S/7f/ub7s+pz+uClOjso8PcgcJf9BS6pQ/9/g/xwxrqQ+ uj9lyhSlMcKjPszNTHm6y9VU4P///7G2tze6cVC+BDFDJXhEPZ3MYRIQESN6Kvceuv///9/bKRhZ ElEXUJ6ZQiA2WT7nTsGPYUSWXKDIHkUoef///2/4gVMtJ/E2KXQ3DEe+8p5axKl47MwE+UlZhVVW 6f+3+K1crSsdF1tlST5OvCYpmo2waRcjv/3/f3sNRNVO3K3s4Fo6Aa1RPagHGBLyQu1B7FVJ//// /+U9Vks+RJ/n5T8QnEEtemCYn/aHSjE3RMpHpy2CGmrZX/j//1G4ZVpOzZYV93yYcV3WQjwtXuXM l7aiTXq3/////+7luBjinUz4HenVQdfKdHmTscOwl2t5ohHHLnkglE170P///zxRK1AYdIMvyrwE FYYEUQXCRhGYK0DBLIzs////v01MW33AJ5EBJZg/8nohxIE1VCu+vRUljCU9LBkpTL/B//+X2S0e or6Evx8awoQ1iIKqzKpLyq3CrW3//1v7Bq03aAeP0Vl1UdPWWr4gcUqRepLIFLkM/v+X/oZAFsq+ roeoc4GpUHEWTRZJFBjCDLW+wiSO3+A3zQr2vfp+rMUEDkVhzv9v/P/MvSVJykWAegNNNQ1yk6g/ UMo0uXhF1zVEA/////+XP6ovDj2yQnRgtcSTPUxWasSsgr41sEV6NZBFN2AEWv/////XixhMMdJs Cj9JTU5HEpf/+BfxKxhDekY92Ed/uS71tv3///+BPVcsJo65yEXYAsK6USzlHBr0Kq3RtUGTqH6Z jjz/v/0vMxDCwUJOzMJP6WYA9pwsujwqygZ7DA9931j4/4krejnpEXJybtbQgQwYAcxCtopV//// /zd4FtVfTXhxP1FRLqwumsF2Tai2cHqXPEZXz33ZAvL0//+/8LM+7TyGnz3PvkfbMvaWPEV3MnK3 GCoUaVsr/9/+/0n/VFddd7eVsgK1zFVxLSFWXDxOylDCgEXIFcT/rf//mXysq3M0fi1AlVpSTBhI KydvWajfScl2Al3o////wodGerI9Z+Bs+fUxmrlghW2CsC4n9zhTfBgY+AX+Xw+xxH4DtGUSyhxJ F/XKcRetz9/4/xdFjL4yTUlTWcq5ysS+ParnXzp2yg//////ywW4RWIywEpaGtHsQEUy4ECok+y6 nHdO91tshknF+0T/////CUdNJy/e6jV9SMTzqZ1/Ie/ik52FA2FOw863gh4mVhH/////JlLLGCCM qjzYKp45IBsYeFfJvT8VquxHoL4+GAjKi4D/////oELMfVF6fzxSyj9FAY6xXz8geHhJyD3EnXmn Dg+Dcsb/////eZ0ydL1GoK/yfktHPe+YqlESRkODqlKeWcUeSUSrahc3/v+l4R3EtyoSqp41ZGdG ocoHoCyZs3X/Rv//Hgl5Fy1PKR/WX3VxIz9hqbt2cpxyS2LR/wv//1BN9JosE834xgFNRzRFlZkZ 7CyoyokwQFQv/////zT37Fye2XE1TwNLwrsCq18fRqhJrl6BAaq5/3UWx0gC/sb/S40xTmpJWK5L 0VMfoOu8yDyxKUvSv/03hTSt1t1H8ux+VhdPBK/D2Qy0v8H/0lH1YPMsTr3E1eLKe2It+DJA//+3 C84WRuW4uE2Zmj1ZT8oIT5hFwt28OVz/////TqpTbjJ8Uv+/MWxhKSVQxr0ss1hYxRq9jY00vRyD pw//L/X/M1BSUHe4kfHIgmpjKtkfHvvwlMPHs0h58L/A/9k1Cf+VdAQyMbYwiX2RFhc8+cyt//// v4Tea1XAeS4/WplKes9mKyV+trAFHjJL5Eqs4HHVnfT///8IQ0WigvfoyhpjJWVnFEo9Zaex8J9x mc9LKdl7///Lv0FhvnaevvbORnKs1sKKvnhpGD9+epw9YTr//4X/DfqFuuyx/w2Z/1J5//aBL530 1izYLLgbPVX/S/z/cGC+dbE3ILpg5DRDyp9Llz2AElztgDcy/7/B/wQY5WeZFomvjNyRTrSxerTC qUIQKV15wHip9P+/4KP3bP2d/OnCvwF6R0k/Qv///5dNd/mc48VlvgVCwrjhT0st/p1VETwRH3qx Py//G/z/sZIlXj92+j9kGEvSXVTqVq67Pgo8QAcEv9H//3qvPZoC7UYphUhsHJ+dHl/DfLcwUIGV QP+F//9NfH4Nhs4+USnRHkCifS+9KdrEnCGrbq/CeP/W//9tNUvbzV2T7kcrrxhJjUVNiUlAdEW9 JtGn1vr//1u3P2C6VBBzPttRvcHlRLwvB1/bbAQBee3f+Leul5Zw0YBMKW7Jk8IvN1cizv//L/TO KVNdN0n0SXFjutjF7HH3aVRRwIOxY1P/////XCz3ExcE3pUXc4Sp2SjCkAFAGK9mfPscgb8VnhKH BIX/////Qhxv1oqELocnhjWJNoggiqQz+FaLM4okjR2MDI8slm3/////1iiOIpGQbpMydorvKNuS lZSXZpYWmRzynXeYL16bJZrAC///nQ6cjDOaNGqfXp4CAqE0oEkcljXd//+/XqVqpH6nF06mqvvv KqlWqG6rBqp+rV6aRKz///8LJROusS/JHLD3tdssknS0b7e2N9+5uNnn9yr/0l/ou1K6NcoFlnu/ bXoEgf5HTxG/S////65uS1xEkFnBOcKDAE8yWFVANG6nLEQ6iAUR2/+/wU9j7djsgDTmgVlBSUkx ooqB4Cckhbr/9rQpAeepj5aGEyQmKDQKMm63///tM4GwBy+SSrOyN5EoIiQMJtvnETMubb2h/7/9 /zZ3N368MjsN+AypxsCIsU8JbIFtIVcbkcapVRL//3/rXeSIfqZxGYFsLLS8NEgBH8CFYIIiRva/ bjH/////uiufHJ0AyEeOAR6qO5gBzaDieFYDyABRgYY3hjxWaEX+Rv//TF9KTQ3KXEULXrzewidJ QU/5oV45uob/v/G3KjGSymztqlk3VdoMKw5KKbtaPGN3/xJ/4x6hqvZqK/JDowd0lH2X9FqFFtv/ Bv8RSXLtjzT+KXAiXDE+BOmIrOwAzFv8//ZuTY4R4nddU0MO974UFMgvWcjlYf9/iYVgDMPyJ54r sD9ZM1z5/vKotyH/////7ONazAZOJll6vUePXDpJM0uVBshKBnf68Zr3P8ggXST//y/9UXKtBhRJ SQz2YRRdZV2GTRGCca3Q7KBkUef9////5T5IFpuBxPGxqsQuFC+Zl5gZ+mk0VuWD4VbBw9ubf4H/ L0tRtkYayrp1AiU+kJ8REYZTCwJJ/4UL/RFsrfMuwdRFNDgUbXytPaBxRrzQ//9EEilRWL/c7GCc Xnn90d9x8/Rl+0DxLX2DC4tLgBVUu1uDB4j///8LNhLLmcu6PbC3/gCCyrvKkIChUSdIgKhD4MLb ////4IRN/7LrHhqAHOT0nb4YpcI/TUE0s4YHTQOUmhJf+v9T7HchpyFTggo+Qm97rI6CEgs4FCr0 /6sPMYT3vFzRBnq4JGf/F/pb+B+OSUIHguzRFWA3OjHI4jRE/////5V5B0lii9SbqWqJCoLua+72 UwbzyB/0Dqp4/uYGh063/////3qOP0cKnoCiQhKakdkqvgOOyBdFNfPKigF0ATKggfQY39rq/4Mm 5IkqlYQsUGE/PMoMwFr7Ff////96SgE1eoM9CNkR0TmJvh/o+VOcNtoRVRiEesqGtpGHcv//N/jm /+y1eMc8Z1N2UWY9yl4seeJwRyh9gCb8W3yrKgxPF4tH71IYRvLYFxT///8vlAa2ehbnc0YJFgh6 gDVQcuL0LEpKiwKDNngtvIn/v/EXHyuDH0XM8+rqvk8eC2EKrAkGx/9/q3+64fqRQ3m/ufhm6tf8 xypQOzl1OxA5of///61pEPVVRhgLtQis6y2xNGC4qcCk56JeiBwH//+/VVw1Q7aUBPW49izIyN6G /g10NJDCZ0Hj32ijK6RZIhy01UCqR5CK/7/9fzZdDDSvEWpccLcKPa2EV7aTcIeBRQg0tTua/y/Q 4q9brXtpHMwvRV+EYaj0C0L6b///zXoNupivNRx6vN9ZI5JoH0nH+jpZNK43Vn+jErcLH/rvhGwg Wa18vhf6t/pqGSzu0J8eWV0OofR+f0UP/////zSabTvDaRJKw4VHmhJ4KKLzIXoBck0quTQDRiB6 MeY0/8b//994X1+sw1esEBbo2Uo8meX327naTWeL5fSb//+/9JyV28oNVMgNoM+LZQ7lmb1e9jv3 0Jm5JVmC/v+l/5tfPZFnXJ3wHpDYFojQ5ydlImWdv5heCF/U4P/fBZE1DBbOvUO96ndyiB7IvWb6 3+Avrsngdht1X/krzKEAf2Uaki////8XBD2mj17UnVEhc3OdSQKxl3oCSmRV5sI8RBg+2/9C/0as 87UL8sXDKXhNEloRyT+WdtDN/////y6FI8VGcC2Ap0MXwMMOfMz9R/5XH6RCYywkypIybBQxv8WN /tGhmng0CCA1SSptuB7DWf+g1NvbHbe9iT9PRNJT9dsb/f/fprdCW1hJgx2qP+KaFKMVkdwViRVH Qv9/62zIARes24pJek5bYpYvzJ9Bif/03+r/8tAhPd4pJiEJQwg2TT8NIeQCgv///3cucXoMUZ4p yvGh/2cGSfpUPalgTV0Z3ELTFPUc/8b/W9LA6GH7jjmIiHL3NUdCF8FBJq1r6f8X/ji6vhw7bVRI 011dGDkXFyceVR3DGnnf+v9/Q7kWB3qHnx85aoLXRT9EM7U1Bfw+fgyW/y/0/2RIF9wX3ZUS9pSu 6upR3Dy9N1tUVBkXRv////+TNlRwzdbhDe+q6hImGDH9I8y2VYgARRd3/DVIERBuVdX/G/xEWWyD Waep2zGwJSfNJoXRFuE3KPC/v+3RvPxRzRfpg8aty0C/8P//xZ2fEYsAqYTJQDOrRDJaeSmGL0tG WmqLyRT/t///4hRLWQ7MjyKvcYcTgVjQZR+8BM0xTeYLJy2uiF/g//+fV1IONItPQqkk3TsH8Bgp lMwRFGNK8fT+L/T/QRPs9GNN+YQ48qt223KBeUI1YAHBfUK//f+3Q7hXQoLLCb4x6N477U33RoeK IUCj6Fdf4Nv/HE2p0AsSEyL3FI5E4r1hOKyAva7f6C/0gFU/C1m5CvS+U8N7RKl9ry/1/1v/cz1L vpz+eqOAcapby19bUsH/v9T/oOket5jYWohaNku2vrhhWABCi3XJTwfJ//+/xKFiHYVOvrtNNPi9 F9DZsS0lGYLyEcL+Bf//L/WaVUFCekBiBCaGAVLNHj866oyuR0m/nfv1/wv/2U03FXNRySxMqin8 FurkQUtNYJ97S////y+32aoSsuTj1w+sGsRNBNhTGDwFqYz8xbhP2aRH/1Lf+kQ5NlOa+fStZYhB tdJC5E5g1db/rf53bbCJ2TlDwFSqT9HKpahvoU73/gsX+JlLyz3x1Ca+Z01Mycw+urf9//+lUkM1 aAo1VkNKtpdKzHK2QoeqaWS5Pir/L/RLiJ5yn6pcQ7aSYp68g/qPvGK/wv//20qeSlZOn/Ritkqf z575EMsq18zZr0J8//+t/4CcL/6xGGoMaStFkq/KSZKhRa1CnMHo+oF/g///SrHzQifDcx9A423E 6G5MentiwNcZAWK1/f///09HZJ8j6ElZmQrKlxoZooOaV7x5xgs0tx+Igzs0mf///y90dgFReS1s bvDvFvtRyoBCbZjkLMBuQ36Ao0Kt4////8hTMg6emaMDoSsBBh76XEAPVfsRoeRq6J4zDJL//9+q U1VkVxBxs7TLVVDJVUkAPMkHLtMzs/+NfuvMCLyCa4S3WhdDgjJhx0kiA1r+/1/qrafoQIBbwlK5 4fGQxPp4HDCi3p43ntf8v9QNng9qv1ULzDUQQpbLRdyR+L/FG51LyUWOijO0RhyeCYB1l////99B TlH4A57EbPf3eSdHzuteUfwwaqbbvRj6+VL5wf+/1P/8jJEuCTNCKzkY1RA0AvGXRs65EUpSbiB8 6///GWPBahXOVUfI9QEvU80qFlQHGhKVekSj+tb/b/FcABLor0RJRna0ovg2oHSG4lYb/2+UK6fg QVwogbzBtha/ArlE/i/9/4LfZ04n4ENagMHEj82JPta5GNmhcoCCHX//9v+tMsCgxOw03qvAuERL VyREV7ksPE3p/////wNWRr/oUWRCzp+fR7G+fEVR7TURBzoZND2CEBf/4SMX/43e+rc0SksYGesd s57tWxEJ9h2ee9/iF/hEIxmqTgpfEL55ZumRtplaN/pb/4FCHxj5Ce5KT7V8x9ErfZvGLvr///+S lsxAXFFQEW5FEXW2z68sWZIfRU7E4+pqcRq6D/8X/jc5emBTzqzGPFHfpFcRbVc0OMpRFsH0t/jt 1hxrw3QRBE7RWJ4hJCffp/9f4m8sJ2GnSzYZGRvAW+LtEVpAWf2H7Vv8//9QiRRMZZ848VxUN3IW +StpyzwoGr8bg1/4BRb6jXmJW3pjQyupG4AGp////5dVYWhfkCmM5VC0GXuQgw7/I9RRYh+rG8RJ MpD9X/r/lkCQq40sMvURYKsEvXa6rpyvTv6OYUVQ/63+S2VwaoDkfQYnwFGe7OI3PaUJ2Pv/X/hq B8zDBvIx+p6z+0cSCWt9R0UBnkKKyT6N/v9/LLxJc4gntpiaC/UaK2y0k4McA07edP9f4P9IO4Cq /9ePR1yE1WwqNfcN1nqFYcqy/CX/////29jl6ZeQd4k5UZKpSreasJzuzNRX5XFcY08UqUvK3EH/ /8L/bGBc65FNbvEEBg5dqf9PASc0uuMKqzOxVC3/X1jos7cE6v0YNXbMzATUwveK6kSmf4m/9ffI IgnGRZsTpv8xEEGAqykMOf////80qNEna6GdSuskprHuTWHVfm8OXaz3tNSkulFhEB3LlP//b/+4 Wgo3wA6nNBMFqEVxVtTumrLRDa48sXO2PK2txP9f4oaHwuEa4FCavLfHSPqgBgRoRv//37oFrZ6o qfn08CYeSEOtfXCqfJG3J+esrapf4v+lMbFCcw4puF+q7jjZzY01HWouUl/g/zc8c4GkyQSlwzH/ 1Vo6nL/L/7/A/1A9bJedl1lNIZxHXqtX7fggRBlhSRylof///1gvbnmqZzwxGGM0pO4VN1jgVDAp jUFBa2Ev/7/Uf0i/2qdpzVFApSAlBygtJFhBvx8SJDX///9GRi4oLvK37fxOFjMoRlsCM2RKLqQe 9wBmf6m/1AYVuCoCLjRMLc+ct4D3M1cE8P//L1YkLDERaClMCfB+mi9wMQd3JEjSL/Uv7S4iY7+n n5rfSSQyMlVgl7j9/zIkCSAvJQ5/+oQ+RSQvIiD+Lr8JgP9WQK0lNC05DyAslv+/wH8lJTOCj0On BIkA6i2XJ5wVKUclPaM/1v///xuIvyyyMTgNLl0NKCMzIDM4c8RunCHYALggTi70//8zEkkvTMH2 JhMOIyswVQQ5w5FfvAUk60v8BRoueShXC9hcAhcgLcTf4P9/Sob3JG0ATg4xWwokOE/mmB2uTnXn Nfi3f4lRSbE2MjEzMSe6PW2K83SxT//ud9/QUVJ18wt4RVZIQIMJU0xDMkm3v0j/GfXSODguDUBD Ik+z5RhlQ1H/L/0Gx0EngI+PzVpFckYZdhq3EU17pf7//2lRRhHPZFpHQi1uGFZh7VdBJf1f8U5K Hbxwq//FOQQnY9G/NyCqRWJ6IW8l/f8vLQMg9qUqTQoBV4FBwSC6Rc1xQo/MiQN5RhRhviGoY/+3 bRFtzAWBvr4Wwoy+qlHRAMt74/+NRzJGBkCaNEbKX8KvvU8zrPlBK90O2BFQgQwyrioOpS7BBzKl cIhzM0zhHdi3ukk9wo41NciEL4jCQvaEDDRhABxMC/y3f8KAQ8C8QbKVwpBAzFVuwrz5TkrxRu7L QwOUpLaoIov+0v8N9EPCg0XIRsKGRcIINrBAjqgNl9i67xYfyLb4NanLKW3NQDbBwm/1tsF+QFbK RsseRVSpNvj9vw6BUceFaLnBqqlAsTtEyGmYt98a5f9MI0iBNQTKJ8zFdd92hXEY67IRH0m+1yUL 1Mv//9ZOSR2dyLg4Rk72RgYRBvgWCbPvFCk3278zN0bIQsKCRaqZEC0gqAJEBeaq+b4AuZBbowMT JTHYIWmGpDXnPddcYJvwxTFX/Ysfgww2SJupB7dJqvQjAHVBCgQTD5yPUf8X9gUNDUEABRcAEQgD QRQSuckHaxoKFhJzHjFtg9VqTe5OAA0GXK8taPCHIoGsYCy21Q9IKBAMQedqtbbAAs6/Ow2oSvgv MCgvNScA8xRFWEVEgYDAGo0WCAjkAQAwCgAkUQW/aSYgqBwBRmluZENEAaDybG9zZRtEzN4V1FNp emUX73/7TEwRQQ5NYXBWaWV3T2YPbm9hbw5Vbm0QLgNycyJud8MvS0VudhBvbnario5dViJhYhg5 iLgdRAx2ZdrukYqYDn1UaW1GKuKstVcaC1FDotu697ELe3BeZy1Mw25fIH5MaWJyTnlBIfZMULRQ YyhLxkQ5tv1iYWxBbAZjWExhtz3sVNMqTXUDeCgbm7VbbBdyYw9+sHQQB/vnWlYdRkNvcHnFRGXa hzdrBoMXJUhh5wsg3cKdRVNj2XY7+WxlblTfcFAvaA1hCwrDVytYRB2zt0VE8W/KkbZQxMlweU2R bFt2Z4IiTRNFeGlCQfFi3WhxZB/xvVnAJv8vmY33hg27BWVwoTZCN+LCw7AzblqcZUl7EXGiy/sX bCD8XnIYVG+TFYaZorhMqQ68JXsTYhENCGNrQ4VvT0RyAeNkZUNop9xdRGw0TW9CeXQiEhQnIpye ua+1LQpjmDYqUqCyvSfhVEdQb2koGUh7wWbtcEYmXL0TGYRDmDDoOm5FTLisMGkJaZwWpCImBDpN GDPXOEN1GH0ZOiQ5YW9rpURlLJWEIMWVaLXHHuObwGcbS2V5DE9w69yjazELRWoOgFZbvQAadnVl D4vM3KWEESl1bTAMT7PNJrc/ZML4baCiYW6Hc2UwijcXa4xyEPYHaXNkvfZcCXoZ8s4QFKJ4rltQ CCI5N6ErMyphKiECSg9ms1TNIAGhVVwPFrDfTkJ1ZmZBDwtMb3f2GbYjd3ZJcpQjdwqFm3Fa9MwM TYLCAKhtWbZN17fYYkD/BAITC2VZlmU0FxIQA6tlWZYPCRRzOb//hLw8UEVMAQPgAA8BCwEHrnvS bBNyKoAyBBADgmxnsZA1CwIzBJlb0s0HDNAeNHvZG9gQBwYAwHkIQIBbZHgCGAVGuMJ2K2R4AR4u L9iToJikcJDrNn+7sAQjIAtgLmRhdGGYI+5CusH7Iid2QL3NYBuFLuUJAMPABny/KXs0J0AbsHsN lAAASkE8CQAAAP8AAAAAAGC+AJBQAI2+AID//1eDzf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHb cu24AQAAAAHbdQeLHoPu/BHbEcAB23PvdQmLHoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHb dQeLHoPu/BHbEckB23UHix6D7vwR2xHJdSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78Edtz5IPB AoH9APP//4PRAY0UL4P9/HYPigJCiAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J 97kBAQAAigdHLOg8AXf3gD8BdfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgDAAACL BwnAdEWLXwSNhDAU5QAAAfNQg8cI/5aM5QAAlYoHRwjAdNyJ+XkHD7cHR1BHuVdI8q5V/5aQ5QAA CcB0B4kDg8ME69j/lpTlAABh6SNE//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAACAAEAAABAAACAAgAAAGgAAIAAAAAAAAAA AAAAAAAAAAEACQQAAFgAAADY8AAA6AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAkEAACAAAAA xPMAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADQAACAqAAAgAAAAAAAAAAAAAAAAAAAAQAJ BAAAwAAAAPD0AAAiAAAAAAAAAAAAAAABADAA4MAAACgAAAAgAAAAQAAAAAEABAAAAAAAgAIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8A AAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIiIiIiIiIiIiIiIiIgAAAj/////////////// /4AAAIf///////////////eAAACPf/////////////9/gAAAj/f////////////3/4AAAI//f/// ////////f/+AAACP//f/////////9///gAAAj///f////////3///4AAAI////f///////f///+A AACP//93d3d3d3d3f///gAAAj//3f39/f39/f3f//4AAAI//d/f39/f39/f3f/+AAACP939/f39/ f39/f3f/gAAAh3f39/f39/f39/f3d4AAAI9/f39/f39/f39/f3+AAACP////////////////AAAA CP//////////////8AAAAACP/////////////wAAAAAACP////////////AAAAAAAACP//////// //8AAAAAAAAACP/////////wAAAAAAAAAACP////////AAAAAAAAAAAACP//////8AAAAAAAAAAA AACP/////wAAAAAAAAAAAAAACIiIiIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD////////////////AAAADwAAAA8AAAAPAAAADwAAAA8AAAAPA AAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAB+AAAA/wAAAf+AAAP/wA AH/+AAD//wAB//+AA///wAf//+AP/////////////////8jDAAAoAAAAEAAAACAAAAABAAQAAAAA AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAA AAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACP//// //8AAIj/////+AAAj4////+PAACP+P//+P8AAI+PiIiPjwAAiPf39/f4AACPf39/f38AAAj39/f3 8AAAAI9/f38AAAAACPf38AAAAAAAiIiAAAAAAAAAAAAAAAAAAAAAAAAA//8AAP//AADAAQAAwAEA AMABAADAAQAAwAEAAMABAADAAQAAwAEAAOADAADwBwAA+A8AAPwfAAD//wAA//8AAPDEAAAAAAEA AgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAAAAC89QAAjPUAAAAAAAAA AAAAAAAAAMn1AACc9QAAAAAAAAAAAAAAAAAA1vUAAKT1AAAAAAAAAAAAAAAAAADh9QAArPUAAAAA AAAAAAAAAAAAAOz1AAC09QAAAAAAAAAAAAAAAAAAAAAAAAAAAAD29QAABPYAABT2AAAAAAAAIvYA AAAAAAAw9gAAAAAAADj2AAAAAAAAOQAAgAAAAABLRVJORUwzMi5ETEwAQURWQVBJMzIuZGxsAE1T VkNSVC5kbGwAVVNFUjMyLmRsbABXUzJfMzIuZGxsAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRy ZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAbWVtc2V0AAB3c3ByaW50ZkEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqwmA4PjmtxyrYEcJq+ZwxKsy 1hmrpGJUVDqrQFSYqSOb/mvKpKmWOBsBlDTIEVyJyBFcNMgRXE3IEZtDyBWVJLMZct7g9oJQjE6M pkZtdUJGwXcwi+DxWeUYfLeMToxFyrG5BLPmdbT15nS0kf0ETz9OQ5U/TkODP0hCnfXmR51wTA09 gH/mqZ+L9OCfqjdCn4n5x5+J/l2AM+6An4oLiHDsBQOfr3+mnwH0rp8KP4qfIDvSnyarfYDfcb6A 3fcMb6LP9YBG8Saf1SPfn5s+LoBtdwSA5Hswn5s+hZ/Ue/Nv9o0xgLFHup/OfnGAMKjEn7lnQ5+5 YXuAHkkvn895H3CQzC6fXjHHn14/Cp/R2a2fSpa7gOcgRp9VNeiA5yBWb2C4L4CmnVaAhoK4gKfi zp8rZYefHQNonx0OoYCEhXNveLV+n0lZkZ9LMbyfwTaPgL1M34CwhuWfHPazgA1WrnFymyOeTkUO ngfl4YFIvHiBESKvgUNvK568ZyKeTq3U+zVwYQsOipYLD1QVC2aOhBT5T9OfGv+tCwyDjBT/3bxv azYIgK04+59RHJCAjQxsn1jMmICkiKGfquz0gIP3xXKl/nOdYA0inZlQ44KWnR2dzGVDneZ0AZ2Z UBKCn9ZHcditnJ72VCyemy9NnuRzgJ4Dhy2BDq10np95C4GmWgxxOtNggQlVgIF1NkmBXpDannm/ 5J627KWe/ygcnn0GcXBjAK2AFxTKn4U6D58k1PyfqS7hn4UqV5+FPgCAB0NSiOUVHuzKZ8RnraDi 7MqKQ3ia9+dnragzZz/ZwmcqoLhw5mFsnyzP85+PFa+f2qeIgN+T458gRU2A14ikgJDSo3A6fwSf 4Er/gAkcl5/gsRqf/S/qn/KRyIBe8vmf0jSWcKd1vIC8uEWfTz6jgJT0U59ij02fm7Nbn21bMoD0 i2xwLPFRgB0adIAdG2+fxDIVgBUNK59rIIyf5l8agBUIDnGQeduB0y0fnktTdp6svIWBWRujnlZs Qp7Xs7merIcH/HgqphOeGACYV2egDEHR4BOcFPsTokjGEz/khAxJwSRxrE5UnmprbZ52g4Geabzh nu9QtZ5KeJ+ed2S+nkQFGDTj1FXbJi3+xNonlcTaIA7bObW3xNo1ydugWjcfaaOrrzyh7V8GtP+S CMnNXwRTSMsTMiRA5XvZQPYPAUB7cKEyrpEU3UZV4MLlVA7CdkNEXGvCbpzI29XdkOyV3Xdn37GB gaNeT3QPXk53eB/l4X1ewhNCQf7e+0HlxW5B0nhIcDbnRYAMxIqAzsDXgA8Top/shs2fdWErn1Ic 5Z/vE5P4dWkFCANEtxdbmIsITJtB3ojKSggbJZnIGrIcF7rTaXD1dYGfMo1hnzN4NoDGBQ6fOs/X nxFKtp87gRifM1Ctb3dJMYCxXN2An4oLgKxjTZ8B+quArSjXn74puYCTdC8jCnWIzMXMKh4HGS3M wFsT03fMPszFy7PMxKnu0zuUsLFLppheZV9yXo20L0Fxj9tBmGRkH9fnaUFyVUxekIwkZ6Yiz4jl s2g0SRVWNEkVM2dYKj6YaQqQZyLl+5hDwaVQSwECFAAKAAAAAADSUuUy2e2+M6BwAACgcAAAsQAA AAAAAAAAACAAAAAAAAAAZG9jdW1lbnQuZG9jICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAuZXhlUEsFBgAAAAABAAEA3wAAAG9xAAAAAA== ------=_NextPart_000_0004_1AF2B4A7.3934DE78 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_000_0004_1AF2B4A7.3934DE78-- From ipv6-bounces@ietf.org Wed Jul 06 18:16:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqIAA-0001b6-49; Wed, 06 Jul 2005 18:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqIA4-0001VL-3a; Wed, 06 Jul 2005 18:14:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03982; Wed, 6 Jul 2005 18:14:29 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqIb8-00083k-Ae; Wed, 06 Jul 2005 18:42:30 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DqIA3-0005n5-3K; Wed, 06 Jul 2005 18:14:31 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 06 Jul 2005 18:14:31 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Protocol Action: 'IPv6 Host to Router Load Sharing' to Proposed Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The IESG has approved the following document: - 'IPv6 Host to Router Load Sharing ' as a Proposed Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-host-load-sharing-04.txt Technical Summary The original IPv6 conceptual sending algorithm does not do load- sharing among equivalent IPv6 routers, and suggests schemes which can be problematic in practice. This document updates the conceptual sending algorithm so that traffic to different destinations can be distributed among routers in an efficient fashion. Working Group Summary The IPv6 working group has done extensive review of this document and this document reflects the consensus of the group. Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list and by the working group chairs. This document was reviewed for the IESG by Margaret Wasserman. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 07 03:28:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQoQ-0003Xk-FI; Thu, 07 Jul 2005 03:28:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNJH-0006St-Md; Wed, 06 Jul 2005 23:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00329; Wed, 6 Jul 2005 23:44:21 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqNkO-0003bt-Gl; Thu, 07 Jul 2005 00:12:24 -0400 Received: from [24.52.170.51] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 423832; Wed, 06 Jul 2005 23:38:41 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jul 2005 23:41:45 -0400 To: int-area@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Thu, 07 Jul 2005 03:28:44 -0400 Cc: Subject: NEW!! Internet Area Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org [This message is bcc:ed to all INT area WGs, the IESG and the IAB.] Hi All, We have created an Internet Area mailing list -- int-area@ietf.org. This list will be used to announce Internet area BOFs, to discuss Internet area WG charter updates and to discuss other issues related to the Internet Area, as they arise -- such as whether we should hold an Internet area meeting in Paris. If you wish to join the list, you can do so at: https://www1.ietf.org/mailman/listinfo/int-area The archives should be available at: http://www.ietf.org/mail-archive/web/int-area/index.html (Hopefully this will be the first message in the archive). If you are interested in issues concerning the overall structure or scope of the Internet area and/or are interested in influencing how the Internet area is managed, I hope you will join this list. Thanks, Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 07 12:44:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZUb-00047L-JI; Thu, 07 Jul 2005 12:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZUZ-000460-5n for ipv6@megatron.ietf.org; Thu, 07 Jul 2005 12:44:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24509 for ; Thu, 7 Jul 2005 12:44:48 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqZvm-0007Ek-Q7 for ipv6@ietf.org; Thu, 07 Jul 2005 13:12:59 -0400 Message-ID: <0e8001c58313$60987a70$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "IPV6 WG" References: Date: Thu, 7 Jul 2005 09:46:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: ICMP Security Problem? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org A friend sent me this reference. I have not looked into this in detail, so this may be a well-known problem: http://kerneltrap.org/node/5382 Any comments? jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 07 12:59:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZiI-0004Sk-G8; Thu, 07 Jul 2005 12:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZiH-0004SQ-6x for ipv6@megatron.ietf.org; Thu, 07 Jul 2005 12:59:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25581 for ; Thu, 7 Jul 2005 12:58:58 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqa9U-0000Wz-1j for ipv6@ietf.org; Thu, 07 Jul 2005 13:27:09 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j67GRRQ08825; Thu, 7 Jul 2005 09:27:27 -0700 X-mProtect: <200507071627> Nokia Silicon Valley Messaging Protection Received: from danira-pool053247.americas.nokia.com (10.241.53.247, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdxEULee; Thu, 07 Jul 2005 09:27:25 PDT Message-Id: <6.2.1.2.2.20050707095056.02f5f4a8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 09:58:31 -0700 To: James Kempf From: Bob Hinden In-Reply-To: <0e8001c58313$60987a70$016115ac@dcml.docomolabsusa.com> References: <0e8001c58313$60987a70$016115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IPV6 WG Subject: Re: ICMP Security Problem? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org James, At 09:46 AM 07/07/2005, James Kempf wrote: >A friend sent me this reference. I have not looked into this in detail, so >this may be a well-known problem: > >http://kerneltrap.org/node/5382 There is a thread on /. about this today as well. I think most of this is old news. The new ICMPv6 update that is being worked on has a major revision to the Security Considerations section that should cover these issues. If I remember correctly, the work in V6OPS that the article refers to was fed into the new ICMPv6 draft. 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 Jul 07 14:15:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqatB-0003SZ-Qz; Thu, 07 Jul 2005 14:14:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqat9-0003RN-SN for ipv6@megatron.ietf.org; Thu, 07 Jul 2005 14:14:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00984 for ; Thu, 7 Jul 2005 14:14:16 -0400 (EDT) Received: from mclean-vscan2.bah.com ([156.80.3.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqbKK-0000hR-DP for ipv6@ietf.org; Thu, 07 Jul 2005 14:42:26 -0400 Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by mclean-vscan2.bah.com (8.11.0/8.11.0) with SMTP id j67IDwS14653; Thu, 7 Jul 2005 14:13:58 -0400 (EDT) Received: from mclnexbh02.resource.ds.bah.com ([156.80.7.152]) by mclean-vscan2.bah.com (SAVSMTP 3.1.6.45) with SMTP id M2005070714135826318 ; Thu, 07 Jul 2005 14:13:58 -0400 Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.122]) by mclnexbh02.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 14:13:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Jul 2005 14:13:57 -0400 Message-ID: <787C235469504E49AC6D9F9ED13738402C43D0@MCLNEXVS05.resource.ds.bah.com> Thread-Topic: ICMP Security Problem? Thread-Index: AcWDFcZ0DFhNztY3RQ2XekwZRBeBdAACaYUQ From: "Lowe Chris" To: "Bob Hinden" X-OriginalArrivalTime: 07 Jul 2005 18:13:58.0377 (UTC) FILETIME=[A4E73D90:01C5831F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: IPV6 WG Subject: RE: ICMP Security Problem? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Bob-- Slashdot is posting old news??? That is so unusual! ;)=20 Chris -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden Sent: Thursday, July 07, 2005 12:59 PM To: James Kempf Cc: IPV6 WG Subject: Re: ICMP Security Problem? James, At 09:46 AM 07/07/2005, James Kempf wrote: >A friend sent me this reference. I have not looked into this in detail, >so this may be a well-known problem: > >http://kerneltrap.org/node/5382 There is a thread on /. about this today as well. I think most of this is old news. The new ICMPv6 update that is being worked on has a major revision to the Security Considerations section that should cover these issues. If I remember correctly, the work in V6OPS that the article refers to was fed into the new ICMPv6 draft. 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 ipv6-bounces@ietf.org Thu Jul 07 15:23:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqby1-00067r-4c; Thu, 07 Jul 2005 15:23:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqbxz-00064L-Bk for ipv6@megatron.ietf.org; Thu, 07 Jul 2005 15:23:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11451 for ; Thu, 7 Jul 2005 15:23:20 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqcPB-0001Jr-Vn for ipv6@ietf.org; Thu, 07 Jul 2005 15:51:31 -0400 Received: (qmail 14025 invoked from network); 7 Jul 2005 19:22:22 -0000 Received: from 200.123.90.54.techtelnet.net (HELO jade.gont.com.ar) (gont-fernando@200.123.90.54) by server.frh.utn.edu.ar with SMTP; 7 Jul 2005 19:22:22 -0000 Message-Id: <6.2.0.14.0.20050707161111.01f55168@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 07 Jul 2005 16:18:59 -0300 To: Bob Hinden , James Kempf From: Fernando Gont In-Reply-To: <6.2.1.2.2.20050707095056.02f5f4a8@mailhost.iprg.nokia.com> References: <0e8001c58313$60987a70$016115ac@dcml.docomolabsusa.com> <6.2.1.2.2.20050707095056.02f5f4a8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IPV6 WG Subject: Re: ICMP Security Problem? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At 01:58 p.m. 07/07/2005, Bob Hinden wrote: >>A friend sent me this reference. I have not looked into this in detail, so >>this may be a well-known problem: >> >>http://kerneltrap.org/node/5382 > >There is a thread on /. about this today as well. I think most of this is >old news. The attacks are not new, and that's acknowledged in the draft. However, there were not counter-measures for them. Have a look at the NISCC and CERT/CC vulnerability reports, and see the number of implementations affected. >The new ICMPv6 update that is being worked on has a major revision to the >Security Considerations section that should cover these issues. Yes. We discussed this some time ago, and Mukesh has already addressed these issues in the ICMPv6 update. >If I remember correctly, the work in V6OPS that the article refers to was >fed into the new ICMPv6 draft. I don't think so. However, the current ICMPv6 update defines the semantics of ICMPv6 error messages, and thus allows anything that runs over IPv6 to handle ICMP error messages in what they think is the best way. Thus allowing the "TCP's reaction to soft errors" thing to be implemented without violating the specs (as is the case with IPv4), for example. The IPv6-related stuff will be updated in the next revision of my draft, which should be ready in the next few days. If you consider it appropriate, I can announce the draft on this list, too, so that we can discuss the v6-specific stuff. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.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 Jul 08 04:05:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqnr4-0007Bi-T9; Fri, 08 Jul 2005 04:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqnr1-0007BV-Ds for ipv6@megatron.ietf.org; Fri, 08 Jul 2005 04:04:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08166 for ; Fri, 8 Jul 2005 04:04:57 -0400 (EDT) Received: from mail.syce.net ([192.16.178.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqoIL-0003vV-S1 for ipv6@ietf.org; Fri, 08 Jul 2005 04:33:15 -0400 Received: from localhost (mail.syce.net [IPv6:2001:218:4fd::25]) by mail.syce.net (8.12.11/8.12.11) with ESMTP/inet6 id j6884g5u053454; Fri, 8 Jul 2005 17:04:42 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Fri, 08 Jul 2005 17:04:42 +0900 (JST) Message-Id: <20050708.170442.295393955.fujisaki@syce.net> To: ipv6@ietf.org From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) X-Mailer: Mew version 4.2 on XEmacs 21.4.15 (Security Through Obscurity) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: Web Page for distibution of the default address selection policy. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, Related to our proposed draft: Title: Distributing Default Address Selection Policy using DHCPv6 Filename: draft-fujisaki-dhc-addr-select-opt-00.txt we've summarized the current implementation status of RFC3484, our proposing mechanism for distributing RFC 3484 policy table, and its practical usages in our web page: http://www.nttv6.net/dass As you know, RFC3484 provides a very powerful function, and we believe our distribution mechanism of the policy table in this RFC will be quite useful. Above page is not complete yet, so we'll appreciate if you give us any suggestions or comments on our draft and web page. Yours sincerely, -- Tomohiro Fujisaki -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 08 12:17:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqvX9-00012g-Rs; Fri, 08 Jul 2005 12:16:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqvX7-0000wO-O1 for ipv6@megatron.ietf.org; Fri, 08 Jul 2005 12:16:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25195 for ; Fri, 8 Jul 2005 12:16:55 -0400 (EDT) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqvyY-0003mu-0f for ipv6@ietf.org; Fri, 08 Jul 2005 12:45:18 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 11B2319751B; Fri, 8 Jul 2005 12:09:55 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j68GGmQh026531; Fri, 8 Jul 2005 12:16:48 -0400 Message-Id: <200507081616.j68GGmQh026531@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jinmei@isl.rdc.toshiba.co.jp References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.com> <200504031817.j33IHHBS028317@bright.research.att.com> <200504040240.j342ebvl008179@bright.research.att.com> <200504041437.j34EbjkS026424@bright.research.att.com> Date: Fri, 8 Jul 2005 12:16:48 -0400 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: uri@w3.org, ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >So, I guess the appropriate next step for this work is to make >consensus on this, which mostly equals to my question -1: > > -1. are we okay with forcing URL/URI parsers to understand the > detailed semantics of the scoped address syntax and to strip the > zone ID (+ delimiter) part by itself for the reason because the > parsers would already need to do some extra work for the special > syntax? Obviously, since I proposed it, I'm OK with it. I haven't seen anyone else with an opinion. Overall, I've seen a handful of "I need this" and one "I've implemented this", lots of misunderstanding about what the proposal is, and a handful of "There's no use for this." There's been some discussion of what the seperator character should be, which is fine but irrelevant if the answer to the bigger question is "no". Since the majority of the comments since the IETF meeting have been negative, I'm inclined to drop this work. I still think it's necessary, but if the major players in the WG push against it then I'm not going to pursue it. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jul 10 00:00:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrSzf-0004cI-EI; Sun, 10 Jul 2005 00:00:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrSzd-0004cD-UK for ipv6@megatron.ietf.org; Sun, 10 Jul 2005 00:00:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15150 for ; Sun, 10 Jul 2005 00:00:34 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrTRJ-0008Rw-ID for ipv6@ietf.org; Sun, 10 Jul 2005 00:29:16 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 95F2A445 for ; Sun, 10 Jul 2005 00:00:16 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 10 Jul 2005 00:00:16 -0400 Message-Id: <20050710040016.95F2A445@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 9.09% | 1 | 51.09% | 42978 | sekiya@wide.ad.jp 9.09% | 1 | 8.74% | 7349 | k.mundra@samsung.com 9.09% | 1 | 5.40% | 4545 | fernando@gont.com.ar 9.09% | 1 | 5.39% | 4533 | fenner@research.att.com 9.09% | 1 | 5.10% | 4292 | lowe_chris@bah.com 9.09% | 1 | 4.46% | 3756 | iesg-secretary@ietf.org 9.09% | 1 | 4.34% | 3655 | sra+ipng@hactrn.net 9.09% | 1 | 4.23% | 3558 | bob.hinden@nokia.com 9.09% | 1 | 4.07% | 3422 | fujisaki@syce.net 9.09% | 1 | 4.03% | 3393 | margaret@thingmagic.com 9.09% | 1 | 3.14% | 2640 | kempf@docomolabs-usa.com --------+------+--------+----------+------------------------ 100.00% | 11 |100.00% | 84121 | 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 ipv6-bounces@ietf.org Mon Jul 11 10:04:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drytx-0002Qb-CY; Mon, 11 Jul 2005 10:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drytu-0002QW-J2 for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 10:04:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13020 for ; Mon, 11 Jul 2005 10:04:48 -0400 (EDT) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrzLt-0000HN-6J for ipv6@ietf.org; Mon, 11 Jul 2005 10:33:47 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j6BE4c4w285810 for ; Mon, 11 Jul 2005 14:04:38 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6BE4cnb276744 for ; Mon, 11 Jul 2005 15:04:38 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j6BE4cLl018231 for ; Mon, 11 Jul 2005 15:04:38 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j6BE4bY0018226 for ; Mon, 11 Jul 2005 15:04:37 +0100 Received: from zurich.ibm.com (sig-9-145-135-119.de.ibm.com [9.145.135.119]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA69068 for ; Mon, 11 Jul 2005 16:04:36 +0200 Message-ID: <42D27C78.2@zurich.ibm.com> Date: Mon, 11 Jul 2005 16:04:40 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: NSAP Address IPv6 option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org RFC 1888 defined a destination option called "NSAP Address" with option type code 11-0-00011 = 195 decimal, C3 hexadecimal. Unfortunately, the IANA Considerations in RFC 4048 faild to discuss this option. It is still listed at http://www.iana.org/assignments/ipv6-parameters My opinion is that it can be released; I'm aware of no usage. Any objections? Can the WG Chairs suggest a procedure to avoid the overhead of another trivial RFC? Sorry )-: 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 Jul 11 11:53:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds0bQ-0000VX-V8; Mon, 11 Jul 2005 11:53:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds0bO-0000VP-PU for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 11:53:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23351 for ; Mon, 11 Jul 2005 11:53:47 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds13K-0005NH-9r for ipv6@ietf.org; Mon, 11 Jul 2005 12:22:48 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1Ds0b0-0000SZ-BC for ipv6@ietf.org; Mon, 11 Jul 2005 16:53:26 +0100 Message-ID: <42D29637.50706@dial.pipex.com> Date: Mon, 11 Jul 2005 16:54:31 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPv6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Late breaking thought... Paragraph 2 of Section 7.2.1 of draft-ietf-ipv6-2461bis-03.txt says that joining and leaving the solicited-node multicast group SHOULD be done using MLD (and the reference is to RFC2710 i.e., MLDv1). We now have MLDv2.. RFC3810.. Should something be said about this? If I understand the compatibility section RFC3810 correctly, if hosts continue to generate MLDv1 Listener Reports the routers will be forced to operate in MLDv1 compatibility mode for the solicited-node multicast addresses, perpetuating this mode for ever. Is this desirable? Presumably this can only be handled by providing a configuration flag which would tell an interface to send MLDv2 Listener Reports instead of MLDv1 ones. Regards, Elwyn Davies -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 11 13:18:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1vL-0008Se-J4; Mon, 11 Jul 2005 13:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1vJ-0008SX-V4 for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 13:18:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02681 for ; Mon, 11 Jul 2005 13:18:26 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds2NL-0000Yi-0y for ipv6@ietf.org; Mon, 11 Jul 2005 13:47:28 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6BGkhX30242; Mon, 11 Jul 2005 09:46:43 -0700 X-mProtect: <200507111646> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp160188.americas.nokia.com (10.241.160.188, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdAXirGT; Mon, 11 Jul 2005 09:46:41 PDT Message-Id: <6.2.1.2.2.20050711100352.02d448b0@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 11 Jul 2005 10:17:59 -0700 To: Brian E Carpenter From: Bob Hinden In-Reply-To: <42D27C78.2@zurich.ibm.com> References: <42D27C78.2@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IPv6 Subject: Re: NSAP Address IPv6 option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Brian, At 07:04 AM 07/11/2005, Brian E Carpenter wrote: >RFC 1888 defined a destination option called "NSAP Address" >with option type code 11-0-00011 = 195 decimal, C3 hexadecimal. > >Unfortunately, the IANA Considerations in RFC 4048 >faild to discuss this option. It is still listed at >http://www.iana.org/assignments/ipv6-parameters > >My opinion is that it can be released; I'm aware of no usage. > >Any objections? Can the WG Chairs suggest a procedure to avoid >the overhead of another trivial RFC? The chairs could send an email to the IANA (with cc's to the IPv6 list and IESG) with something to the effect that since RFC4048 made RFC1888 historic, the destination option defined by RFC1888 is no longer needed and should be marked as Reserved. This was the intention of RFC4048, but was omitted in error. The only downside of this approach I can think of is that there wouldn't be an RFC documenting the change. I am not sure this is a big deal in this case. Other opinions and/or suggestions? Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 11 14:38:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3AO-00031P-IC; Mon, 11 Jul 2005 14:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3AN-00031K-60 for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 14:38:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08829 for ; Mon, 11 Jul 2005 14:38:05 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds3cL-0003dz-Ee for ipv6@ietf.org; Mon, 11 Jul 2005 15:07:06 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA28832; Mon, 11 Jul 2005 13:37:34 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6BIbXs07117; Mon, 11 Jul 2005 11:37: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.211); Mon, 11 Jul 2005 11:37:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Jul 2005 11:37:32 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4F33@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: NSAP Address IPv6 option Thread-Index: AcWGPuY9ZY9Z9EaPScuI5fmMbP4FoAACIX4w From: "Templin, Fred L" To: "Bob Hinden" , "Brian E Carpenter" X-OriginalArrivalTime: 11 Jul 2005 18:37:33.0292 (UTC) FILETIME=[99E922C0:01C58647] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: IPv6 Subject: RE: NSAP Address IPv6 option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Why not just post this as errata to RFC4048? Fred=20 -----Original Message----- From: Bob Hinden [mailto:bob.hinden@nokia.com]=20 Sent: Monday, July 11, 2005 10:18 AM To: Brian E Carpenter Cc: IPv6 Subject: Re: NSAP Address IPv6 option Brian, At 07:04 AM 07/11/2005, Brian E Carpenter wrote: >RFC 1888 defined a destination option called "NSAP Address" >with option type code 11-0-00011 =3D 195 decimal, C3 hexadecimal. > >Unfortunately, the IANA Considerations in RFC 4048 >faild to discuss this option. It is still listed at >http://www.iana.org/assignments/ipv6-parameters > >My opinion is that it can be released; I'm aware of no usage. > >Any objections? Can the WG Chairs suggest a procedure to avoid >the overhead of another trivial RFC? The chairs could send an email to the IANA (with cc's to the IPv6 list and=20 IESG) with something to the effect that since RFC4048 made RFC1888=20 historic, the destination option defined by RFC1888 is no longer needed and=20 should be marked as Reserved. This was the intention of RFC4048, but was=20 omitted in error. The only downside of this approach I can think of is that there wouldn't be=20 an RFC documenting the change. I am not sure this is a big deal in this case. Other opinions and/or suggestions? 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 ipv6-bounces@ietf.org Mon Jul 11 17:07:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5Uf-00078O-TE; Mon, 11 Jul 2005 17:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5Ua-00077y-RY for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 17:07:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16269 for ; Mon, 11 Jul 2005 17:07:06 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds5wd-000185-QI for ipv6@ietf.org; Mon, 11 Jul 2005 17:36:09 -0400 Received: (qmail 7634 invoked from network); 11 Jul 2005 21:05:57 -0000 Received: from 200.123.90.205.techtelnet.net (HELO jade.gont.com.ar) (gont-fernando@200.123.90.205) by server.frh.utn.edu.ar with SMTP; 11 Jul 2005 21:05:57 -0000 Message-Id: <6.2.0.14.0.20050711165153.03b929a8@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 11 Jul 2005 18:05:11 -0300 To: Bob Hinden , James Kempf From: Fernando Gont In-Reply-To: <6.2.1.2.2.20050707095056.02f5f4a8@mailhost.iprg.nokia.com> References: <0e8001c58313$60987a70$016115ac@dcml.docomolabsusa.com> <6.2.1.2.2.20050707095056.02f5f4a8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IPV6 WG Subject: Re: ICMP Security Problem? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At 01:58 p.m. 07/07/2005, Bob Hinden wrote: >>http://kerneltrap.org/node/5382 > >There is a thread on /. about this today as well. I think most of this is >old news. The new ICMPv6 update that is being worked on has a major >revision to the Security Considerations section that should cover these >issues. If I remember correctly, the work in V6OPS that the article >refers to was fed into the new ICMPv6 draft. As far as I understand, PMTUD is mandatory for IPv6. The current specifications make it quite trivial to attack it. Think about an attacker exploiting these vulnerabilities to attack a BGP router. While these problems have been known, the existing specifications don't recommend any validation checks on the received ICMP error messages. Checking the TCP SEQ number does its job. However, it puts you in the same position as for the "Slipping in the window" attacks raised last year. The more complete PMTUD fix described in http://www.gont.com.ar/draft/draft-gont-tcpm-icmp-attacks-03.txt protects you from attack, regardless of whether the attacker is able to hit you "in the window" or not. The news with this work is not the vulnerabilities, but the fixes, and the raise of awareness in the community. Have a look at NISCC's and CERT/CC's vulnerability reports, and see the large number of systems affected. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.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 Jul 11 17:44:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds655-0003sC-AW; Mon, 11 Jul 2005 17:44:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds653-0003s1-AN for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 17:44:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19232 for ; Mon, 11 Jul 2005 17:44:46 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds6X5-0002a0-M9 for ipv6@ietf.org; Mon, 11 Jul 2005 18:13:50 -0400 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.1783381; Mon, 11 Jul 2005 17:44:21 -0400 In-Reply-To: <42D29637.50706@dial.pipex.com> References: <42D29637.50706@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: Brian Haberman Date: Mon, 11 Jul 2005 17:44:20 -0400 To: Elwyn Davies X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: IPv6 Subject: Re: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org 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="===============1152888555==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1152888555== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--1070343811; protocol="application/pkcs7-signature" --Apple-Mail-7--1070343811 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jul 11, 2005, at 11:54, Elwyn Davies wrote: > Late breaking thought... > > Paragraph 2 of Section 7.2.1 of draft-ietf-ipv6-2461bis-03.txt says > that joining and leaving the solicited-node multicast group SHOULD be > done using MLD (and the reference is to RFC2710 i.e., MLDv1). We now > have MLDv2.. RFC3810.. Should something be said about this? Since the MLD reference is Informative, it could be augmented to mention both 2710 and 3810. > > If I understand the compatibility section RFC3810 correctly, if hosts > continue to generate MLDv1 Listener Reports the routers will be forced > to operate in MLDv1 compatibility mode for the solicited-node > multicast addresses, perpetuating this mode for ever. Is this > desirable? Presumably this can only be handled by providing a > configuration flag which would tell an interface to send MLDv2 > Listener Reports instead of MLDv1 ones. > The main, current benefit of MLDv2 is to support source-specific multicast (SSM). However, the NDP use of multicast is non-SSM (ASM or any-source multicast) and does not need MLDv2 capability in order to function correctly. I would support adding an additional reference to 3810 in order to encourage implementors to move up in capability. Regards, Brian --Apple-Mail-7--1070343811 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzExMjE0NDIwWjAjBgkqhkiG9w0B CQQxFgQUCDRKjt71Hp+dDebKFEaIVzs03bMweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAgVKouAvcfcrTPD3kvTgd3mN2EqcFitdPE9/9RDRWqp9OWDX8ccz3nA2aJWexnVjdTb6c OffZnThZyCEecbWSedhyg0mf7nMF2PlH58wbuyM3v81uT8Y91tkms8Hw+eKRcVvJPNeDngjB/ixc S8qgUtqyDLXWotBBfszoyCD0g1FyiuHujZtazs2RX5byvveqPeCYZMhNXHJaA157nbZ6K+k4bdD6 ibf3q1m4ZJM+YrwPtVvEvcmOBPTeh2FoI39OSr+Ksq1W/WpaiUVjgjsFP30yQQYZIKs9wOaFJee5 kesK/i7LkHLSdnv4MQRzuYD7KhFt+LfvqgBvxiLOpKRLTwAAAAAAAA== --Apple-Mail-7--1070343811-- --===============1152888555== 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 -------------------------------------------------------------------- --===============1152888555==-- From ipv6-bounces@ietf.org Mon Jul 11 17:53:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6Dg-0001aX-5P; Mon, 11 Jul 2005 17:53:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6Dd-0001XH-VU for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 17:53:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20696 for ; Mon, 11 Jul 2005 17:53:39 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds6fh-0003Cp-Sn for ipv6@ietf.org; Mon, 11 Jul 2005 18:22:43 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6BLrSIh026315; Mon, 11 Jul 2005 23:53:28 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6BLrSo1015672; Mon, 11 Jul 2005 23:53:28 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6BLrSkF015671; Mon, 11 Jul 2005 23:53:28 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 11 Jul 2005 23:53:28 +0200 From: Stig Venaas To: Brian Haberman Message-ID: <20050711215328.GG14789@storhaugen.uninett.no> References: <42D29637.50706@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IPv6 Subject: Re: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Mon, Jul 11, 2005 at 05:44:20PM -0400, Brian Haberman wrote: [...] > The main, current benefit of MLDv2 is to support source-specific > multicast > (SSM). However, the NDP use of multicast is non-SSM (ASM or any-source > multicast) and does not need MLDv2 capability in order to function > correctly. Yes, so not important, but... > I would support adding an additional reference to 3810 in order to > encourage > implementors to move up in capability. I also think we should encourage this. Might then be able to get rid of MLDv1 and simplify things later on (well, might take a very long time). Stig > > Regards, > 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 Mon Jul 11 18:05:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6Ox-0005UX-MF; Mon, 11 Jul 2005 18:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6Ow-0005Sq-7I for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 18:05:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22010 for ; Mon, 11 Jul 2005 18:05:19 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds6qt-0003hV-L2 for ipv6@ietf.org; Mon, 11 Jul 2005 18:34:23 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1Ds6OV-0003f7-Pe; Mon, 11 Jul 2005 23:04:55 +0100 Message-ID: <42D2ED4A.50704@dial.pipex.com> Date: Mon, 11 Jul 2005 23:06:02 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas References: <42D29637.50706@dial.pipex.com> <20050711215328.GG14789@storhaugen.uninett.no> In-Reply-To: <20050711215328.GG14789@storhaugen.uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , IPv6 Subject: Re: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org My understanding that as well as a reference to MLDv2 we would need to mention that if any of the routers are 'legacy' that support only MLDv1, then any MLDv2 routers would have to have their configuration flags set to make them operate in MLDv1 compatibility mode. Hosts on the other hand willl behave correctly whether they are MLDv2 or only MLDv1 capable. Regards, Elwyn Stig Venaas wrote: >On Mon, Jul 11, 2005 at 05:44:20PM -0400, Brian Haberman wrote: >[...] > > >>The main, current benefit of MLDv2 is to support source-specific >>multicast >>(SSM). However, the NDP use of multicast is non-SSM (ASM or any-source >>multicast) and does not need MLDv2 capability in order to function >>correctly. >> >> > >Yes, so not important, but... > > > >>I would support adding an additional reference to 3810 in order to >>encourage >>implementors to move up in capability. >> >> > >I also think we should encourage this. Might then be able to get rid of >MLDv1 and simplify things later on (well, might take a very long time). > >Stig > > > >>Regards, >>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 Mon Jul 11 18:16:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6Zn-0003RX-GN; Mon, 11 Jul 2005 18:16:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6Zl-0003QU-La for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 18:16:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24578 for ; Mon, 11 Jul 2005 18:16:30 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds71p-0004Vl-O4 for ipv6@ietf.org; Mon, 11 Jul 2005 18:45:35 -0400 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.1784384; Mon, 11 Jul 2005 18:16:04 -0400 In-Reply-To: <42D2ED4A.50704@dial.pipex.com> References: <42D29637.50706@dial.pipex.com> <20050711215328.GG14789@storhaugen.uninett.no> <42D2ED4A.50704@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <7d10f9b18d46f89aaea0d6ccb08f1718@innovationslab.net> From: Brian Haberman Date: Mon, 11 Jul 2005 18:16:03 -0400 To: Elwyn Davies X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: IPv6 , Stig Venaas Subject: Re: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org 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="===============1900748611==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1900748611== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--1068440552; protocol="application/pkcs7-signature" --Apple-Mail-8--1068440552 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jul 11, 2005, at 18:06, Elwyn Davies wrote: > My understanding that as well as a reference to MLDv2 we would need to > mention that if any of the routers are 'legacy' that support only > MLDv1, then any MLDv2 routers would have to have their configuration > flags set to make them operate in MLDv1 compatibility mode. Hosts on > the other hand willl behave correctly whether they are MLDv2 or only > MLDv1 capable. I don't think we want to add MLD configuration guidance in 2461bis. If someone is running a mix of MLDv1 and MLDv2 routers, they need to be aware of the operational guidance provided in RFC 3810. Brian --Apple-Mail-8--1068440552 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzExMjIxNjA0WjAjBgkqhkiG9w0B CQQxFgQUDUrBod9L0WnhNVxZwMv4hK1aFuMweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAE3wExbNP2BTdqfHTxYBl61XsNq3ng0gfNZ9Ci3CJTXbYZWC5wo6NC4D7Q0opOERukV/V KOdd3xY/4sKUxEqDjnsFYPtDVNPgkIw5t+24e8OinPs8x35d76VDStll2c92lg4HitLFugLsKL+B YvhV2VXcC+jObuApKnuMiMwUWo9MaqmO1BwLtwuz3pnYjLlo2jseGInx08Qhfy+EIxWkBFm95fFj 7UQjTWUkytbUEMFwLr7A5njo0fnbpsqwM5+64MMqFhApZRj8PpPsJTLjWPMhm6sX/LKh4OKsJ4MV Kz5J5nPfCdnt8Nx1h6/4f8OEkfI7PdwUcdvks9MG+RWKvgAAAAAAAA== --Apple-Mail-8--1068440552-- --===============1900748611== 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 -------------------------------------------------------------------- --===============1900748611==-- From ipv6-bounces@ietf.org Mon Jul 11 18:23:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6gR-0005kj-FN; Mon, 11 Jul 2005 18:23:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6gP-0005kS-DN for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 18:23:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25807 for ; Mon, 11 Jul 2005 18:23:22 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds78U-0004vH-He for ipv6@ietf.org; Mon, 11 Jul 2005 18:52:27 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6BMNMIh001379; Tue, 12 Jul 2005 00:23:22 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6BMNMIh015769; Tue, 12 Jul 2005 00:23:22 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6BMNLhC015768; Tue, 12 Jul 2005 00:23:21 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 12 Jul 2005 00:23:21 +0200 From: Stig Venaas To: Brian Haberman Message-ID: <20050711222321.GI14789@storhaugen.uninett.no> References: <42D29637.50706@dial.pipex.com> <20050711215328.GG14789@storhaugen.uninett.no> <42D2ED4A.50704@dial.pipex.com> <7d10f9b18d46f89aaea0d6ccb08f1718@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d10f9b18d46f89aaea0d6ccb08f1718@innovationslab.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IPv6 Subject: Re: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Mon, Jul 11, 2005 at 06:16:03PM -0400, Brian Haberman wrote: > > On Jul 11, 2005, at 18:06, Elwyn Davies wrote: > > >My understanding that as well as a reference to MLDv2 we would need to > >mention that if any of the routers are 'legacy' that support only > >MLDv1, then any MLDv2 routers would have to have their configuration > >flags set to make them operate in MLDv1 compatibility mode. Hosts on > >the other hand willl behave correctly whether they are MLDv2 or only > >MLDv1 capable. > > I don't think we want to add MLD configuration guidance in 2461bis. If > someone is > running a mix of MLDv1 and MLDv2 routers, they need to be aware of the > operational > guidance provided in RFC 3810. Also, the issue with MLDv1 and MLDv2 routers on the same link is totally independent of this. Whenever you mix such routers on a link you need to do this and it is not for specific groups either. So routers would have to be configured the same independent of what 2461bis says. Stig > > 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 Mon Jul 11 18:25:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6iD-0006ck-Bp; Mon, 11 Jul 2005 18:25:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6iB-0006cc-Sl for ipv6@megatron.ietf.org; Mon, 11 Jul 2005 18:25:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26159 for ; Mon, 11 Jul 2005 18:25:12 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds7AG-00053f-8n for ipv6@ietf.org; Mon, 11 Jul 2005 18:54:17 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 11 Jul 2005 18:25:00 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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, 11 Jul 2005 18:24:59 -0400 Message-ID: Thread-Topic: MLDv2 and RFC2461bis Thread-Index: AcWGZrkoTO+1gwxoQ5+7SeneHeilIAAAILmA From: "Soliman, Hesham" To: "Brian Haberman" , "Elwyn Davies" X-OriginalArrivalTime: 11 Jul 2005 22:25:00.0228 (UTC) FILETIME=[601E5040:01C58667] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: IPv6 , Stig Venaas Subject: RE: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > > My understanding that as well as a reference to MLDv2 we=20 > would need to=20 > > mention that if any of the routers are 'legacy' that support only=20 > > MLDv1, then any MLDv2 routers would have to have their=20 > configuration=20 > > flags set to make them operate in MLDv1 compatibility=20 > mode. Hosts on=20 > > the other hand willl behave correctly whether they are=20 > MLDv2 or only=20 > > MLDv1 capable. >=20 > I don't think we want to add MLD configuration guidance in=20 > 2461bis. If=20 > someone is > running a mix of MLDv1 and MLDv2 routers, they need to be=20 > aware of the=20 > operational > guidance provided in RFC 3810. =3D> Agreed. This seems like a 3810 issue of how to manage different versions on the same link (or ban it).=20 Hesham >=20 > Brian >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 12 03:09:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsEt4-0007iA-Nk; Tue, 12 Jul 2005 03:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsEt2-0007hw-VG for ipv6@megatron.ietf.org; Tue, 12 Jul 2005 03:09:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24923 for ; Tue, 12 Jul 2005 03:08:59 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsFL4-0006R4-6j for ipv6@ietf.org; Tue, 12 Jul 2005 03:38:06 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DsEsc-000359-7O; Tue, 12 Jul 2005 08:08:34 +0100 Message-ID: <42D36CB3.2060700@dial.pipex.com> Date: Tue, 12 Jul 2005 08:09:39 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Brian Haberman , IPv6 , Stig Venaas Subject: Re: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a very purist view. Even if you don't tell them what to do, at least give them a hint that they ought to think about the issue. I suggest you put in a pointer to s.8 of 3810. Regards, Elwyn Soliman, Hesham wrote: > > > My understanding that as well as a reference to MLDv2 we > > would need to > > > mention that if any of the routers are 'legacy' that support only > > > MLDv1, then any MLDv2 routers would have to have their > > configuration > > > flags set to make them operate in MLDv1 compatibility > > mode. Hosts on > > > the other hand willl behave correctly whether they are > > MLDv2 or only > > > MLDv1 capable. > > > > I don't think we want to add MLD configuration guidance in > > 2461bis. If > > someone is > > running a mix of MLDv1 and MLDv2 routers, they need to be > > aware of the > > operational > > guidance provided in RFC 3810. > >=> Agreed. This seems like a 3810 issue of how to manage different >versions on the same link (or ban it). > >Hesham > > > > > Brian > > > >=========================================================== >This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. >=========================================================== > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 12 03:22:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsF5r-0003JB-BV; Tue, 12 Jul 2005 03:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsF5p-0003Fq-IZ for ipv6@megatron.ietf.org; Tue, 12 Jul 2005 03:22:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26127 for ; Tue, 12 Jul 2005 03:22:12 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsFXy-000738-OH for ipv6@ietf.org; Tue, 12 Jul 2005 03:51:19 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Jul 2005 03:21: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: Tue, 12 Jul 2005 03:21:57 -0400 Message-ID: Thread-Topic: MLDv2 and RFC2461bis Thread-Index: AcWGsIIKJeXoGsjBRRy0iwLZxyTSwQAAZxBg From: "Soliman, Hesham" To: "Elwyn Davies" X-OriginalArrivalTime: 12 Jul 2005 07:21:57.0747 (UTC) FILETIME=[63419430:01C586B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: Brian Haberman , IPv6 , Stig Venaas Subject: RE: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > This is a very purist view. Even if you don't tell them=20 > what to do, at=20 > least give them a hint that they ought to think about the issue. > I suggest you put in a pointer to s.8 of 3810. =3D> I don't think there is a problem with adding a hint. The issue is 2461bis is not the right place for it. I guess whoever updates 3810 in future can consider this point. For now I think it's sufficient to add a reference in 2461bis. Hesham >=20 > Regards, > Elwyn >=20 > Soliman, Hesham wrote: >=20 > > > > My understanding that as well as a reference to MLDv2 we=20 > > > would need to=20 > > > > mention that if any of the routers are 'legacy' that=20 > support only=20 > > > > MLDv1, then any MLDv2 routers would have to have their=20 > > > configuration=20 > > > > flags set to make them operate in MLDv1 compatibility=20 > > > mode. Hosts on=20 > > > > the other hand willl behave correctly whether they are=20 > > > MLDv2 or only=20 > > > > MLDv1 capable. > > >=20 > > > I don't think we want to add MLD configuration guidance in=20 > > > 2461bis. If=20 > > > someone is > > > running a mix of MLDv1 and MLDv2 routers, they need to be=20 > > > aware of the=20 > > > operational > > > guidance provided in RFC 3810. > > > >=3D> Agreed. This seems like a 3810 issue of how to manage different > >versions on the same link (or ban it).=20 > > > >Hesham > > > > >=20 > > > Brian > > >=20 > > > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >This email may contain confidential and privileged material=20 > for the sole use > > of the intended recipient. Any review or distribution by=20 > others is strictly > > prohibited. If you are not the intended recipient please=20 > contact the sender > > and delete all copies. > = >=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 > > > > =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 Tue Jul 12 03:48:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFVA-00038z-M6; Tue, 12 Jul 2005 03:48:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFV8-00038t-Lz for ipv6@megatron.ietf.org; Tue, 12 Jul 2005 03:48:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28001 for ; Tue, 12 Jul 2005 03:48:21 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsFxD-0008Dl-KP for ipv6@ietf.org; Tue, 12 Jul 2005 04:17:29 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DsFV1-00040o-6U; Tue, 12 Jul 2005 08:48:15 +0100 Message-ID: <42D375FF.6040607@dial.pipex.com> Date: Tue, 12 Jul 2005 08:49:19 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" 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: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , IPv6 , Stig Venaas Subject: Re: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I was thinking of something along the lines of: ...joining and leaving the solicited-node multicast group SHOULD be done using MLD v1 [MLD] or v2 {RFC3810]. Section 8 of [RFC3810] explains how nodes using MLDv1 and MLDv2 can coexist on a link. Elwyn Soliman, Hesham wrote: > > This is a very purist view. Even if you don't tell them > > what to do, at > > least give them a hint that they ought to think about the issue. > > I suggest you put in a pointer to s.8 of 3810. > >=> I don't think there is a problem with adding a hint. The issue >is 2461bis is not the right place for it. I guess whoever updates >3810 in future can consider this point. For now I think it's >sufficient to add a reference in 2461bis. > >Hesham > > > > > Regards, > > Elwyn > > > > Soliman, Hesham wrote: > > > > > > > My understanding that as well as a reference to MLDv2 we > > > > would need to > > > > > mention that if any of the routers are 'legacy' that > > support only > > > > > MLDv1, then any MLDv2 routers would have to have their > > > > configuration > > > > > flags set to make them operate in MLDv1 compatibility > > > > mode. Hosts on > > > > > the other hand willl behave correctly whether they are > > > > MLDv2 or only > > > > > MLDv1 capable. > > > > > > > > I don't think we want to add MLD configuration guidance in > > > > 2461bis. If > > > > someone is > > > > running a mix of MLDv1 and MLDv2 routers, they need to be > > > > aware of the > > > > operational > > > > guidance provided in RFC 3810. > > > > > >=> Agreed. This seems like a 3810 issue of how to manage different > > >versions on the same link (or ban it). > > > > > >Hesham > > > > > > > > > > > Brian > > > > > > > > > >=========================================================== > > >This email may contain confidential and privileged material > > for the sole use > > > of the intended recipient. Any review or distribution by > > others is strictly > > > prohibited. If you are not the intended recipient please > > contact the sender > > > and delete all copies. > > >=========================================================== > > > > > > > > > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 12 09:58:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsLHm-0006YV-Nf; Tue, 12 Jul 2005 09:58:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsLHk-0006YC-86 for ipv6@megatron.ietf.org; Tue, 12 Jul 2005 09:58:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23014 for ; Tue, 12 Jul 2005 09:58:54 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsLjw-0005K3-La for ipv6@ietf.org; Tue, 12 Jul 2005 10:28:05 -0400 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.1814594; Tue, 12 Jul 2005 09:58:29 -0400 In-Reply-To: <42D375FF.6040607@dial.pipex.com> References: <42D375FF.6040607@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: Brian Haberman Date: Tue, 12 Jul 2005 09:58:27 -0400 To: Elwyn Davies X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: "Soliman, Hesham" , IPv6 , Stig Venaas Subject: Re: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org 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="===============0400522438==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0400522438== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--1011896325; protocol="application/pkcs7-signature" --Apple-Mail-3--1011896325 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jul 12, 2005, at 3:49, Elwyn Davies wrote: > I was thinking of something along the lines of: > > ...joining and leaving the solicited-node multicast group SHOULD be > done using MLD v1 [MLD] or v2 {RFC3810]. Section 8 of [RFC3810] > explains how nodes using MLDv1 and MLDv2 can coexist on a link. > Two things with this suggestion. First, the above text may be seen as a Normative reference to RFC 3810. That won't work for 2461bis given that 3810 is PS. The second issue is that I still don't see the benefit of adding operational guidelines for MLD in this spec. I agree with Hesham that it belongs somewhere and that somewhere is section 8 of RFC 3810. If someone recognizes that they are mixing MLD versions, then I would hope/expect that they are aware of the guidelines in 3810 already before they get to any issues in 2461bis. To me, it would be similar to having text providing hints on interoperability between DHCPv6 and DHCPv6-lite (as an example). Regards, Brian --Apple-Mail-3--1011896325 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzEyMTM1ODI4WjAjBgkqhkiG9w0B CQQxFgQU7QTeMJJAHtSeOKeOXypQikImjC4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAX3OnxtxmiJVPRGi4CaS7Q/Xdvnxv3DzR31St7+BdLoSN5bTQbjfh5anmig3dUIoOVUe7 FqW0zG4R8/5CUQ4YDN2MOX3ucGKffGMnouVraWp4sKfHi2xoRp8mNUpCXYJtfDcPEpb1tJr1sYh0 XvgwZhdk9G6CUHoLSZLTE9ib/U9zTaUzjRVfZ2+rDKh7GYF3Jz+k5k+aD34Py6/sH2krcroi2H5Y sIP8c496ebKe7twY1Zfk9bv85NKOhUwIb7RRJGjKkSG7VD+yWAbuJTf3btgbgwaOzE3zosCM0r4Y l41tukSdXYu4N3NcKGzJAyU8WuWg0IgKeQADyXzmnxBmJgAAAAAAAA== --Apple-Mail-3--1011896325-- --===============0400522438== 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 -------------------------------------------------------------------- --===============0400522438==-- From ipv6-bounces@ietf.org Tue Jul 12 10:37:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsLt6-000758-72; Tue, 12 Jul 2005 10:37:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsLt3-00072E-QW for ipv6@megatron.ietf.org; Tue, 12 Jul 2005 10:37:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28741 for ; Tue, 12 Jul 2005 10:37:28 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsMLB-0007Ie-FF for ipv6@ietf.org; Tue, 12 Jul 2005 11:06:39 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DsLsg-00086Z-B1; Tue, 12 Jul 2005 15:37:06 +0100 Message-ID: <42D3D5D3.3030900@dial.pipex.com> Date: Tue, 12 Jul 2005 15:38:11 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: <42D375FF.6040607@dial.pipex.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: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , IPv6 , Stig Venaas Subject: Re: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I can see that the world is against me here ;-) , but I am not sure that giving in quietly is actually the right answer in this case! If you are offering alternatives, it is a legitimate question to ask whether all nodes in some context have to use the same alternative to achieve interoperability - we know that they don't have to and can say so in one short sentence! Brian Haberman wrote: > > On Jul 12, 2005, at 3:49, Elwyn Davies wrote: > >> I was thinking of something along the lines of: >> >> ...joining and leaving the solicited-node multicast group SHOULD be >> done using MLD v1 [MLD] or v2 {RFC3810]. Section 8 of [RFC3810] >> explains how nodes using MLDv1 and MLDv2 can coexist on a link. >> > > Two things with this suggestion. First, the above text may be seen as a > Normative reference to RFC 3810. That won't work for 2461bis given that > 3810 is PS. I have to say that this would be a rather hair splitting view, but you may well be right - I am not sure that saying you SHOULD use something is not normative but that pointing someone to a section of the document in case they do use it makes it normative. > The second issue is that I still don't see the benefit of adding > operational guidelines for MLD in this spec. I agree with Hesham that it > belongs somewhere and that somewhere is section 8 of RFC 3810. or maybe in node requirements? Anyway is this really an operational guideline? I am not proposing you say what to do but rather that we *have* thought about it and 3810 has the answer. > > If someone recognizes that they are mixing MLD versions, then I would > hope/expect that they are aware of the guidelines in 3810 already before > they get to any issues in 2461bis. To me, it would be similar to having > text providing hints on interoperability between DHCPv6 and DHCPv6-lite > (as an example). It seems to me that there is a difference here: whether or not 2461bis says SHOULD use MLD all the routers around appear to implement MLD and (AFAIK) turn it on by default. People endeavouring to use IPv6 for unicast who are not interested in multicast may know little or nothing, and care less about MLD (sorry). People who are using DHCP are making a poitive choice for it. However, be that as it may, router vendors are going to have to point this issue out to their clients, and they need to be reminded to do so by some means. Enough of this - Just make sure it doesn't get lost down the cracks! Regards, Elwyn > > 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 Tue Jul 12 12:56:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsO41-0006Xq-Qh; Tue, 12 Jul 2005 12:56:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsO3y-0006X9-V7 for ipv6@megatron.ietf.org; Tue, 12 Jul 2005 12:56:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15731 for ; Tue, 12 Jul 2005 12:56:52 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsOWD-0006QX-4N for ipv6@ietf.org; Tue, 12 Jul 2005 13:26:06 -0400 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.1825172; Tue, 12 Jul 2005 12:56:24 -0400 In-Reply-To: <42D3D5D3.3030900@dial.pipex.com> References: <42D375FF.6040607@dial.pipex.com> <42D3D5D3.3030900@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <28dca6dcbbe52de6873275a5ba90b383@innovationslab.net> From: Brian Haberman Date: Tue, 12 Jul 2005 12:56:23 -0400 To: Elwyn Davies X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: "Soliman, Hesham" , IPv6 , Stig Venaas Subject: Re: MLDv2 and RFC2461bis X-BeenThere: ipv6@ietf.org 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="===============1498645390==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1498645390== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--1001220690; protocol="application/pkcs7-signature" --Apple-Mail-8--1001220690 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Elwyn, On Jul 12, 2005, at 10:38, Elwyn Davies wrote: > I can see that the world is against me here ;-) , but I am not sure > that giving in quietly is actually the right answer in this case! > If you are offering alternatives, it is a legitimate question to ask > whether all nodes in some context have to use the same alternative to > achieve interoperability - we know that they don't have to and can say > so in one short sentence! > Perhaps a review of Section 8.3.2 of RFC 3810 will clarify the issue. The multicast-capable routers that support MLDv2 will manage MLDv1 compatibility mode per multicast address. That is, it will only revert to MLDv1 mode for those addresses in MLDv1 Report messages. The routers will retain MLDv2 mode for other addresses that are being reported in MLDv2 Report messages. Since the addresses at issue here are link-local in scope, having them reported in an MLDv1 Report will not adversely affect the multicast infrastructure supporting SSM via MLDv2. Regards, Brian --Apple-Mail-8--1001220690 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzEyMTY1NjI0WjAjBgkqhkiG9w0B CQQxFgQURzaCBfNyhPN594k5urxcyIHZrGsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAhYu+g+/sFPCWM9lHvk6j4YRUQ/fgffXawpK3DrGfIskdveEOH9ZTP3dVtluQ0QsrvTEg yG/SdeNYfAaxcjRPHJ9T+XGXc5/BhRvZEkNnRapQhhqwfDjo2rsPg+skYUIEn5+K8twWJTq0Rqm3 Fzxwzo0aNJLGdSygGsOftEIE6ZhknFot8xw1jXRKDDGyj5S8q1BHb0mf6AunxZHXK6qwsgffn1F1 DbUJVYyuqPmPuKeH/MOO6o4HM1lWlpfcwcBGR+LKco4I2YyIgu+CjvNK6HHzduxpGo/iBAHML0dG XlOklHTTO3zrTgV7GAYDSp6plSo/d0mhuYo8Scf4yC0+uwAAAAAAAA== --Apple-Mail-8--1001220690-- --===============1498645390== 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 -------------------------------------------------------------------- --===============1498645390==-- From ipv6-bounces@ietf.org Wed Jul 13 17:44:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsp1i-0005B7-GN; Wed, 13 Jul 2005 17:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsp1g-0005Az-IR for ipv6@megatron.ietf.org; Wed, 13 Jul 2005 17:44:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16612 for ; Wed, 13 Jul 2005 17:44:16 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DspU7-0003dr-Jd for ipv6@ietf.org; Wed, 13 Jul 2005 18:13:45 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j6DLi3JB028901 for ; Wed, 13 Jul 2005 17:44:03 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6DLi3g6262642 for ; Wed, 13 Jul 2005 17:44:03 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j6DLi33k014126 for ; Wed, 13 Jul 2005 17:44:03 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-254-153.mts.ibm.com [9.65.254.153]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j6DLi22P014043 for ; Wed, 13 Jul 2005 17:44:03 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j6DLi2r5006080 for ; Wed, 13 Jul 2005 23:44:02 +0200 Message-Id: <200507132144.j6DLi2r5006080@cichlid.raleigh.ibm.com> To: ipv6@ietf.org Date: Wed, 13 Jul 2005 23:44:02 +0200 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Here's an ID for consideration by the IPv6 WG. Background: Discussion on the more general topic took place at the April ARIN and May RIPE meetings. A good summary of those presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf A more general discussion of the overall topic of IPv6 address allocation considerations (the /48 boundary topic is just one piece of a larger puzzle) can be found at: http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-considerations-00.txt Thomas ------- Forwarded Message From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Date: Tue, 12 Jul 2005 15:50:03 -0400 Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt Reply-To: internet-drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Address Allocation to End Sites Author(s) : T. Narten, et al. Filename : draft-narten-ipv6-3177bis-48boundary-00.txt Pages : 8 Date : 2005-7-12 This document revisits the IAB/IESG recommendations on the assignment of IPv6 address space to end sites. Specifically, it indicates that changing the default end-site assignment for typical home and SOHO sites from /48 to /56 is consistent with the goals of IPv6 and RFC 3177. Although it is for the RIR community to make adjustments to the IPv6 address space allocation and end site assignment policies, the IETF community would be comfortable with RIRs changing the default assignment size to /56 for smaller end sites. This document obsoletes RFC 3177 and reclassifies it as historic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-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-narten-ipv6-3177bis-48boundary-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-narten-ipv6-3177bis-48boundary-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: <2005-7-12130012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-narten-ipv6-3177bis-48boundary-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-12130012.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 13 23:28:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsuOk-0000LF-SN; Wed, 13 Jul 2005 23:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsuOi-0000Ky-Pt for ipv6@megatron.ietf.org; Wed, 13 Jul 2005 23:28:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06220 for ; Wed, 13 Jul 2005 23:28:26 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsurE-0004Wp-Kd for ipv6@ietf.org; Wed, 13 Jul 2005 23:57:58 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:81fc:41ca:8071:ca81]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7BDEE1521A; Thu, 14 Jul 2005 12:33:13 +0900 (JST) Date: Thu, 14 Jul 2005 12:27:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200507081616.j68GGmQh026531@bright.research.att.com> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.com> <200504031817.j33IHHBS028317@bright.research.att.com> <200504040240.j342ebvl008179@bright.research.att.com> <200504041437.j34EbjkS026424@bright.research.att.com> <200507081616.j68GGmQh026531@bright.research.att.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: uri@w3.org, ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 8 Jul 2005 12:16:48 -0400, >>>>> Bill Fenner said: >> So, I guess the appropriate next step for this work is to make >> consensus on this, which mostly equals to my question -1: >> >> -1. are we okay with forcing URL/URI parsers to understand the >> detailed semantics of the scoped address syntax and to strip the >> zone ID (+ delimiter) part by itself for the reason because the >> parsers would already need to do some extra work for the special >> syntax? > Obviously, since I proposed it, I'm OK with it. I haven't seen anyone > else with an opinion. > Overall, I've seen a handful of "I need this" and one "I've > implemented this", lots of misunderstanding about what the > proposal is, and a handful of "There's no use for this." > There's been some discussion of what the seperator character > should be, which is fine but irrelevant if the answer to the bigger > question is "no". > Since the majority of the comments since the IETF meeting have > been negative, I'm inclined to drop this work. I still think it's > necessary, but if the major players in the WG push against it then > I'm not going to pursue it. To be clear, I'm not necessarily negative about the goal of this proposal now that (I believe) I understand the point correctly. In the beginning of the discussion, I didn't understand the proposal assumed additional requirements for URL/URI parsers, so I didn't understand its usefulness. **If we can allow that**, I see this can be useful, while it should be minor usage, with your scenario of configuring a cheap access router using a web interface and router's link-local address. But I simply could not believe the majority of this group would allow that, considering the fact that the majority was very eager to kill site-local addresses, saying "never force applications to do any additional work to deal with scopes". Hence, "question -1" above. I don't have a strong opinion about the 'bigger question', but if I were to answer it with yes-or-no, I'd say yes I'm okay. As you pointed out, we've actually not seen many opinions on the bigger question. I'm not sure how we can interpret this silence, but if we can declare acceptance with "no objection and one or a few positive responses", it may make sense to proceed to the next step. 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 Jul 14 03:32:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyDA-0004gp-Oe; Thu, 14 Jul 2005 03:32:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyD8-0004gk-TH for ipv6@megatron.ietf.org; Thu, 14 Jul 2005 03:32:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13100 for ; Thu, 14 Jul 2005 03:32:45 -0400 (EDT) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsyfe-00043F-LD for ipv6@ietf.org; Thu, 14 Jul 2005 04:02:18 -0400 Received: from [158.64.134.206] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001145299.msg for ; Thu, 14 Jul 2005 09:32:42 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 14 Jul 2005 09:31:18 +0200 From: JORDI PALET MARTINEZ To: "ipv6@ietf.org" Message-ID: In-Reply-To: <200507132144.j6DLi2r5006080@cichlid.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 158.64.134.206 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-4.1 required=5.0 tests=BAYES_00,TO_ADDRESS_EQ_REAL autolearn=ham version=2.64 X-Spam-Processed: consulintel.es, Thu, 14 Jul 2005 09:32:43 +0200 X-MDAV-Processed: consulintel.es, Thu, 14 Jul 2005 09:32:45 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Thomas, I've read yesterday this document, and I'm basically ok with it, but with two considerations that I think must be worked out it parallel somehow: 1) HD-Ratio modification, as it seems to be an integral part of the discussion. 2) I've the feeling that if we suggest the ISPs to move to a /56, they will then charge the customers (SOHO, end-users) or create to them a lot of troubles to get a bigger prefix when this is needed. My feeling is that today we believe that 8 bits for subnetting is enough, but I think will not be the case soon and this barrier will then be again a stopper for enabling innovation. I know this one is somehow not an IETF business, but we must be worried about that and may be collectively work for the appropriate solution in the appropriate fora. Otherwise, I will much prefer not to change the /48 to something smaller. Note that I don't think the RIRs are neither a good fora for making a policy which avoids that the addresses are being charged at all (hopefully I'm wrong !). The cost of managing addresses is not a recurrent cost. I mean, it will be ok to charge for a reasonable setup fee if somebody ask for a /48 instead of a /56, but charging 12Euros (or even more) per month per address as some telcos do in EU is a crime. We need to make sure that anything like that happens with IPv6 ! Otherwise, we better stop deploying IPv6 now. Regards, Jordi > De: Thomas Narten > Responder a: > Fecha: Wed, 13 Jul 2005 23:44:02 +0200 > Para: "ipv6@ietf.org" > Asunto: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > Here's an ID for consideration by the IPv6 WG. > > Background: > > Discussion on the more general topic took place at the April ARIN and > May RIPE meetings. A good summary of those presentations can be found > at: > > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv > 6-roundtable-report.pdf > > A more general discussion of the overall topic of IPv6 address > allocation considerations (the /48 boundary topic is just one piece of > a larger puzzle) can be found at: > > http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-considerations- > 00.txt > > Thomas > > ------- Forwarded Message > > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Date: Tue, 12 Jul 2005 15:50:03 -0400 > Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > Reply-To: internet-drafts@ietf.org > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IPv6 Address Allocation to End Sites > Author(s) : T. Narten, et al. > Filename : draft-narten-ipv6-3177bis-48boundary-00.txt > Pages : 8 > Date : 2005-7-12 > > This document revisits the IAB/IESG recommendations on the assignment > of IPv6 address space to end sites. Specifically, it indicates that > changing the default end-site assignment for typical home and SOHO > sites from /48 to /56 is consistent with the goals of IPv6 and RFC > 3177. Although it is for the RIR community to make adjustments to the > IPv6 address space allocation and end site assignment policies, the > IETF community would be comfortable with RIRs changing the default > assignment size to /56 for smaller end sites. This document obsoletes > RFC 3177 and reclassifies it as historic. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.tx> t > > 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-narten-ipv6-3177bis-48boundary-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-narten-ipv6-3177bis-48boundary-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: <2005-7-12130012.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-narten-ipv6-3177bis-48boundary-00.txt"; > site="ftp.ietf.org"; access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <2005-7-12130012.I-D@ietf.org> > > > --OtherAccess-- > > --NextPart > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > --NextPart-- > > ------- End of Forwarded Message > > -------------------------------------------------------------------- > 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 Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com 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 Jul 14 03:52:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyWN-00071x-El; Thu, 14 Jul 2005 03:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyWJ-00071s-1t for ipv6@megatron.ietf.org; Thu, 14 Jul 2005 03:52:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14552 for ; Thu, 14 Jul 2005 03:52:33 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsyys-00054e-9p for ipv6@ietf.org; Thu, 14 Jul 2005 04:22:06 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j6E7qJT24652; Thu, 14 Jul 2005 10:52:23 +0300 Date: Thu, 14 Jul 2005 10:52:19 +0300 (EEST) From: Pekka Savola To: Thomas Narten In-Reply-To: <200507132144.j6DLi2r5006080@cichlid.raleigh.ibm.com> Message-ID: References: <200507132144.j6DLi2r5006080@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: ipv6@ietf.org Subject: Re: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, 13 Jul 2005, Thomas Narten wrote: > Here's an ID for consideration by the IPv6 WG. IMHO, v6ops WG would be more appropriate for this kind of work. > Background: > > Discussion on the more general topic took place at the April ARIN and > May RIPE meetings. A good summary of those presentations can be found > at: > > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf > > A more general discussion of the overall topic of IPv6 address > allocation considerations (the /48 boundary topic is just one piece of > a larger puzzle) can be found at: > > http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-considerations-00.txt > > Thomas > > ------- Forwarded Message > > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Date: Tue, 12 Jul 2005 15:50:03 -0400 > Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > Reply-To: internet-drafts@ietf.org > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 Address Allocation to End Sites > Author(s) : T. Narten, et al. > Filename : draft-narten-ipv6-3177bis-48boundary-00.txt > Pages : 8 > Date : 2005-7-12 > > This document revisits the IAB/IESG recommendations on the assignment > of IPv6 address space to end sites. Specifically, it indicates that > changing the default end-site assignment for typical home and SOHO > sites from /48 to /56 is consistent with the goals of IPv6 and RFC > 3177. Although it is for the RIR community to make adjustments to the > IPv6 address space allocation and end site assignment policies, the > IETF community would be comfortable with RIRs changing the default > assignment size to /56 for smaller end sites. This document obsoletes > RFC 3177 and reclassifies it as historic. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-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-narten-ipv6-3177bis-48boundary-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-narten-ipv6-3177bis-48boundary-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: <2005-7-12130012.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-narten-ipv6-3177bis-48boundary-00.txt"; > site="ftp.ietf.org"; access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <2005-7-12130012.I-D@ietf.org> > > > --OtherAccess-- > > --NextPart > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > --NextPart-- > > ------- End of Forwarded Message > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- 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 Thu Jul 14 04:18:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyoo-0000Oa-P9; Thu, 14 Jul 2005 04:11:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyol-0000OU-LB for ipv6@megatron.ietf.org; Thu, 14 Jul 2005 04:11:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16002 for ; Thu, 14 Jul 2005 04:11:35 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DszHI-0005qx-TL for ipv6@ietf.org; Thu, 14 Jul 2005 04:41:09 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j6E8BM2a779410 for ; Thu, 14 Jul 2005 04:11:22 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6E8BM5b232250 for ; Thu, 14 Jul 2005 02:11:22 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6E8BLsG010229 for ; Thu, 14 Jul 2005 02:11:21 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-226-23.mts.ibm.com [9.65.226.23]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j6E8BKGF010201; Thu, 14 Jul 2005 02:11:21 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j6E8BJgl014068; Thu, 14 Jul 2005 10:11:20 +0200 Message-Id: <200507140811.j6E8BJgl014068@cichlid.raleigh.ibm.com> To: jordi.palet@consulintel.es In-Reply-To: Message from JORDI PALET MARTINEZ of "Thu, 14 Jul 2005 09:31:18 +0200." Date: Thu, 14 Jul 2005 10:11:19 +0200 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "ipv6@ietf.org" Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Jordi. > I've read yesterday this document, and I'm basically ok with it, but with > two considerations that I think must be worked out it parallel somehow: > 1) HD-Ratio modification, as it seems to be an integral part of the > discussion. IMO, changing the HD-ratio is a no-brainer, and I suspect that many people feel the same way. It's an easy change to make and has minimal impact. Indeed, there is already an ARIN proposal to do this: http://www.arin.net/policy/proposals/2005_5.html So yes, I expect this will be done and will personally push to see this happen. > 2) I've the feeling that if we suggest the ISPs to move to a /56, they will > then charge the customers (SOHO, end-users) or create to them a lot of > troubles to get a bigger prefix when this is needed. We should be careful NOT to assume that just because something is done one way in IPv4, it will be similar in IPv6. Indeed, I think one of the big cultural changes w.r.t. IPv6 is the notion that end sites get subnets (emphasis on plural) where this is clearly NOT the norm for IPv4 today. My sense is (from talking to folk in the RIR community) is that they all believe this, and that ISPs working with IPv6 also get this. So I think we've already changed the starting point here. Also, in IPv4, the existing practice is to give out a single address. There are multiple reasons for this, some cultural (i.e., status quo). But another point that I think people sometimes forget is that the existing protocols and busines practices have been built around giving out a single address (rather than a subnet) and such, getting a subnet is, in fact, an exception to the norm. As we know, exceptions can cost more, i.e., in terms of help desk support, etc. So even though ISPs in IPv4 do tend to charge more for "more than one address", the reasons for that are a bit subtle, and when they say its because "more address just cost more", that is really just FUD. In no case can the case be made that it is because the extra addresses actually "cost more", i.e., in terms of RIR policies. Again, my sense in the RIR regions is that folk want the RIR policies to be very clear that addresses should be available to end sites at very low cost (i.e., essentially free), and that the cost of a /48 should be the same as a /56 or /64. And with DHCPv6 prefix delegation (as the protocol/operational mechanism for achieving this) I think we are on track to see the right thing happen. To ensure that happens, the RIR policies will need to be sure that when LIRs need more space from RIRs, the justification should be based entirely on whether the existing space is sufficiently utilized (based on the HD-ratio) with the metric being completely neutral as to whether end sites are getting /48s or /56s. > My feeling is that today we believe that 8 bits for subnetting is > enough, but I think will not be the case soon and this barrier will > then be again a stopper for enabling innovation. I think there is a general feeling in the RIR community that folks that ask for more than a /56 should generally get it more-or-less by asking. I'd welcome help in how to word this. What we don't want is folk automatically asking for a /48 "just because they can". In practice, a /56 will really be enough for a large percentage of end sites, for a long while. Hence, the current "justification" for space is probably best expressed in terms of size of a site in terms of subnets. That is something objectively measurable and captures the sense of whether additional space is really needed. > I know this one is somehow not an IETF business, but we must be > worried about that and may be collectively work for the appropriate > solution in the appropriate fora. We simply need to pay attention to what is going on in the RIR community, and followup as appropriate. The good news is that my own sense (from going to ARIN meetings for 3 years or so, and attending the last RIPE meeting) is that the community there largely shares the same goals as I'm hearing here. They do understand that IPv6 is different than IPv4 and that we need to focus less on conservation than IPv4. I think that most of the community is actually quite happy about this. > The cost of managing addresses is not a recurrent cost. I mean, it will be > ok to charge for a reasonable setup fee if somebody ask for a /48 instead of > a /56, but charging 12Euros (or even more) per month per address as some > telcos do in EU is a crime. No. I think there is no justification (in increased $$) for a /48 vs. a /56. The RIR policies should be clear about that. That won't prevent ISPs from (perhaps) doing this, but they will use weaker arguments like "a /48 implies more traffic and therefore more $$". But then again maybe not. In practice, with a /56, end sites can generate plenty of traffic and ISP charges may end up having to switch to something based on actual traffice being carried. 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 Jul 14 05:32:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt052-0002zr-1z; Thu, 14 Jul 2005 05:32:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt04y-0002zm-FY for ipv6@megatron.ietf.org; Thu, 14 Jul 2005 05:32:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23452 for ; Thu, 14 Jul 2005 05:32:26 -0400 (EDT) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt0XV-0001MQ-84 for ipv6@ietf.org; Thu, 14 Jul 2005 06:02:01 -0400 Received: from [158.64.134.206] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001145727.msg for ; Thu, 14 Jul 2005 11:33:10 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 14 Jul 2005 11:31:31 +0200 From: JORDI PALET MARTINEZ To: "ipv6@ietf.org" Message-ID: In-Reply-To: <200507140811.j6E8BJgl014068@cichlid.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 158.64.134.206 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-4.1 required=5.0 tests=BAYES_00,TO_ADDRESS_EQ_REAL autolearn=ham version=2.64 X-Spam-Processed: consulintel.es, Thu, 14 Jul 2005 11:33:12 +0200 X-MDAV-Processed: consulintel.es, Thu, 14 Jul 2005 11:33:17 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit Cc: global-v6@lists.apnic.net Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Thomas, I totally agree with your appreciations. May be one possibility to ensure that this is going to work also with the RIRs is to hold this document until the RIRs policy changes align to it, and work pro-actively with them in order to make that happening ASAP ? I will suggest a small change to this text (section 2): "... While that number may make sense for larger sites, it is hard to imagine a typical home user requiring so much space. Indeed, the default end site assignment today is in practice the same for home users and larger businesses." For something such as: "... While that number may make sense for larger sites, it is hard to imagine, at the time being, a typical home user requiring so much space, but this can change and we must be ready and open to that. Indeed, the default end site assignment today is in practice the same for home users and large businesses. Moreover, the change in the recommended assignment (from /48 to /56) should not become a barrier for any customer to get a /48 from the ISP, whenever the ISP is required for that, with no need for further justifications for that request." One open question is if this change will impact in the default allocation of /32 to the LIRs. I mean, should they still keep considering that the customers will be able to request a /48 and consequently keep allocating the big prefixes that we have seen until now ? If not, should the big prefixes already allocated be claimed back ? Yes, I know is a RIR business, but I think otherwise we clarify it ASAP, it can create a lot of unfairness in the process with future allocations. Moreover, it will be a good suggestion for ISPs to block the remaining /56 up to the /48 for each customer, in case he ask for it, in order to avoid renumbering ? If that's the case, there is any meaning for this change towards the conservation ?. Note that there is already some people proposing that the business model for IPv6 is precisely charging for the addresses, which I believe is totally broken and a wrong approach. The business will come because there are new services and applications, for which the ISPs will be able to charge, either because the service itself or the BW required by the service, or a combination of both. This will not happen if the addresses aren't available for free (the applications will never come in that case, and we will end-up with a NATv6 model). Also some ISPs in AP are already providing only a /64 and charging for a different "service class" if the customer ask for several subnets. Regards, Jordi (note: I've copied the globa-v6 list as suggested in previous emails from Thomas) > De: Thomas Narten > Responder a: > Fecha: Thu, 14 Jul 2005 10:11:19 +0200 > Para: > CC: "ipv6@ietf.org" > Asunto: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > Hi Jordi. > >> I've read yesterday this document, and I'm basically ok with it, but with >> two considerations that I think must be worked out it parallel somehow: >> 1) HD-Ratio modification, as it seems to be an integral part of the >> discussion. > > IMO, changing the HD-ratio is a no-brainer, and I suspect that many > people feel the same way. It's an easy change to make and has minimal > impact. Indeed, there is already an ARIN proposal to do this: > > http://www.arin.net/policy/proposals/2005_5.html > > So yes, I expect this will be done and will personally push to see > this happen. > >> 2) I've the feeling that if we suggest the ISPs to move to a /56, they will >> then charge the customers (SOHO, end-users) or create to them a lot of >> troubles to get a bigger prefix when this is needed. > > We should be careful NOT to assume that just because something is done > one way in IPv4, it will be similar in IPv6. > > Indeed, I think one of the big cultural changes w.r.t. IPv6 is the > notion that end sites get subnets (emphasis on plural) where this is > clearly NOT the norm for IPv4 today. My sense is (from talking to folk > in the RIR community) is that they all believe this, and that ISPs > working with IPv6 also get this. So I think we've already changed the > starting point here. > > Also, in IPv4, the existing practice is to give out a single > address. There are multiple reasons for this, some cultural (i.e., > status quo). But another point that I think people sometimes forget is > that the existing protocols and busines practices have been built > around giving out a single address (rather than a subnet) and such, > getting a subnet is, in fact, an exception to the norm. As we know, > exceptions can cost more, i.e., in terms of help desk support, etc. > > So even though ISPs in IPv4 do tend to charge more for "more than one > address", the reasons for that are a bit subtle, and when they say its > because "more address just cost more", that is really just FUD. In no > case can the case be made that it is because the extra addresses > actually "cost more", i.e., in terms of RIR policies. > > Again, my sense in the RIR regions is that folk want the RIR policies > to be very clear that addresses should be available to end sites at > very low cost (i.e., essentially free), and that the cost of a /48 > should be the same as a /56 or /64. And with DHCPv6 prefix delegation > (as the protocol/operational mechanism for achieving this) I think we > are on track to see the right thing happen. > > To ensure that happens, the RIR policies will need to be sure that > when LIRs need more space from RIRs, the justification should be > based entirely on whether the existing space is sufficiently utilized > (based on the HD-ratio) with the metric being completely neutral as to > whether end sites are getting /48s or /56s. > >> My feeling is that today we believe that 8 bits for subnetting is >> enough, but I think will not be the case soon and this barrier will >> then be again a stopper for enabling innovation. > > I think there is a general feeling in the RIR community that folks > that ask for more than a /56 should generally get it more-or-less by > asking. I'd welcome help in how to word this. What we don't want is > folk automatically asking for a /48 "just because they can". In > practice, a /56 will really be enough for a large percentage of end > sites, for a long while. Hence, the current "justification" for space > is probably best expressed in terms of size of a site in terms of > subnets. That is something objectively measurable and captures the > sense of whether additional space is really needed. > >> I know this one is somehow not an IETF business, but we must be >> worried about that and may be collectively work for the appropriate >> solution in the appropriate fora. > > We simply need to pay attention to what is going on in the RIR > community, and followup as appropriate. The good news is that my own > sense (from going to ARIN meetings for 3 years or so, and attending > the last RIPE meeting) is that the community there largely shares the > same goals as I'm hearing here. They do understand that IPv6 is > different than IPv4 and that we need to focus less on conservation > than IPv4. I think that most of the community is actually quite happy > about this. > >> The cost of managing addresses is not a recurrent cost. I mean, it will be >> ok to charge for a reasonable setup fee if somebody ask for a /48 instead of >> a /56, but charging 12Euros (or even more) per month per address as some >> telcos do in EU is a crime. > > No. I think there is no justification (in increased $$) for a /48 > vs. a /56. The RIR policies should be clear about that. That won't > prevent ISPs from (perhaps) doing this, but they will use weaker > arguments like "a /48 implies more traffic and therefore more $$". But > then again maybe not. In practice, with a /56, end sites can generate > plenty of traffic and ISP charges may end up having to switch to > something based on actual traffice being carried. > > Thomas > > -------------------------------------------------------------------- > 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 Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com 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 Jul 14 08:42:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt32k-000363-Mr; Thu, 14 Jul 2005 08:42:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt32f-00033J-Od for ipv6@megatron.ietf.org; Thu, 14 Jul 2005 08:42:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04949 for ; Thu, 14 Jul 2005 08:42:16 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3V7-0007xm-VP for ipv6@ietf.org; Thu, 14 Jul 2005 09:11:52 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6ECa6PD012042; Thu, 14 Jul 2005 15:36:23 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 12:59:13 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 12:59:13 +0300 Received: from 10.241.59.70 ([10.241.59.70]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Jul 2005 09:59:11 +0000 Received: from localhost.localdomain by ESEBE100.noe.nokia.com; 14 Jul 2005 12:59:19 +0300 From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Thomas Narten In-Reply-To: <200507140811.j6E8BJgl014068@cichlid.raleigh.ibm.com> References: <200507140811.j6E8BJgl014068@cichlid.raleigh.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1121335158.6004.52.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 14 Jul 2005 12:59:18 +0300 X-OriginalArrivalTime: 14 Jul 2005 09:59:13.0237 (UTC) FILETIME=[B0129850:01C5885A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , jordi.palet@consulintel.es Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thomas and Jordi, I of course share the worry that the operators will start charging differently different size end-user allocations. However, I feel there is little we can do about the in the IETF and therefore I would see that we should not use too much time on this. I think the only practical thing we can do is to advice that the end-user network will have enough addresses to satisfy its communication needs to avoid the introduction of e.g. NAT into IPv6 networks. Cheers, Jonne. On Thu, 2005-07-14 at 11:11, ext Thomas Narten wrote: > Hi Jordi. > > > I've read yesterday this document, and I'm basically ok with it, but with > > two considerations that I think must be worked out it parallel somehow: > > 1) HD-Ratio modification, as it seems to be an integral part of the > > discussion. > > IMO, changing the HD-ratio is a no-brainer, and I suspect that many > people feel the same way. It's an easy change to make and has minimal > impact. Indeed, there is already an ARIN proposal to do this: > > http://www.arin.net/policy/proposals/2005_5.html > > So yes, I expect this will be done and will personally push to see > this happen. > > > 2) I've the feeling that if we suggest the ISPs to move to a /56, they will > > then charge the customers (SOHO, end-users) or create to them a lot of > > troubles to get a bigger prefix when this is needed. > > We should be careful NOT to assume that just because something is done > one way in IPv4, it will be similar in IPv6. > > Indeed, I think one of the big cultural changes w.r.t. IPv6 is the > notion that end sites get subnets (emphasis on plural) where this is > clearly NOT the norm for IPv4 today. My sense is (from talking to folk > in the RIR community) is that they all believe this, and that ISPs > working with IPv6 also get this. So I think we've already changed the > starting point here. > > Also, in IPv4, the existing practice is to give out a single > address. There are multiple reasons for this, some cultural (i.e., > status quo). But another point that I think people sometimes forget is > that the existing protocols and busines practices have been built > around giving out a single address (rather than a subnet) and such, > getting a subnet is, in fact, an exception to the norm. As we know, > exceptions can cost more, i.e., in terms of help desk support, etc. > > So even though ISPs in IPv4 do tend to charge more for "more than one > address", the reasons for that are a bit subtle, and when they say its > because "more address just cost more", that is really just FUD. In no > case can the case be made that it is because the extra addresses > actually "cost more", i.e., in terms of RIR policies. > > Again, my sense in the RIR regions is that folk want the RIR policies > to be very clear that addresses should be available to end sites at > very low cost (i.e., essentially free), and that the cost of a /48 > should be the same as a /56 or /64. And with DHCPv6 prefix delegation > (as the protocol/operational mechanism for achieving this) I think we > are on track to see the right thing happen. > > To ensure that happens, the RIR policies will need to be sure that > when LIRs need more space from RIRs, the justification should be > based entirely on whether the existing space is sufficiently utilized > (based on the HD-ratio) with the metric being completely neutral as to > whether end sites are getting /48s or /56s. > > > My feeling is that today we believe that 8 bits for subnetting is > > enough, but I think will not be the case soon and this barrier will > > then be again a stopper for enabling innovation. > > I think there is a general feeling in the RIR community that folks > that ask for more than a /56 should generally get it more-or-less by > asking. I'd welcome help in how to word this. What we don't want is > folk automatically asking for a /48 "just because they can". In > practice, a /56 will really be enough for a large percentage of end > sites, for a long while. Hence, the current "justification" for space > is probably best expressed in terms of size of a site in terms of > subnets. That is something objectively measurable and captures the > sense of whether additional space is really needed. > > > I know this one is somehow not an IETF business, but we must be > > worried about that and may be collectively work for the appropriate > > solution in the appropriate fora. > > We simply need to pay attention to what is going on in the RIR > community, and followup as appropriate. The good news is that my own > sense (from going to ARIN meetings for 3 years or so, and attending > the last RIPE meeting) is that the community there largely shares the > same goals as I'm hearing here. They do understand that IPv6 is > different than IPv4 and that we need to focus less on conservation > than IPv4. I think that most of the community is actually quite happy > about this. > > > The cost of managing addresses is not a recurrent cost. I mean, it will be > > ok to charge for a reasonable setup fee if somebody ask for a /48 instead of > > a /56, but charging 12Euros (or even more) per month per address as some > > telcos do in EU is a crime. > > No. I think there is no justification (in increased $$) for a /48 > vs. a /56. The RIR policies should be clear about that. That won't > prevent ISPs from (perhaps) doing this, but they will use weaker > arguments like "a /48 implies more traffic and therefore more $$". But > then again maybe not. In practice, with a /56, end sites can generate > plenty of traffic and ISP charges may end up having to switch to > something based on actual traffice being carried. > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.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 Jul 14 10:34:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4nW-0000BL-19; Thu, 14 Jul 2005 10:34:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4nT-0000BB-8R for ipv6@megatron.ietf.org; Thu, 14 Jul 2005 10:34:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13954 for ; Thu, 14 Jul 2005 10:34:41 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt5G0-0003YA-6I for ipv6@ietf.org; Thu, 14 Jul 2005 11:04:18 -0400 Received: from [10.0.0.103] (unknown [151.197.176.58]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id F06C3568D3; Thu, 14 Jul 2005 07:34:20 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <1121335158.6004.52.camel@localhost.localdomain> References: <200507140811.j6E8BJgl014068@cichlid.raleigh.ibm.com> <1121335158.6004.52.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20D0256B-AC70-4258-80F3-4BF118265682@nominum.com> Content-Transfer-Encoding: 7bit From: David Conrad Date: Thu, 14 Jul 2005 07:34:17 -0700 To: Soininen Jonne (Nokia-NET/Helsinki) X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ext Thomas Narten , "ipv6@ietf.org" , jordi.palet@consulintel.es Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, On Jul 14, 2005, at 2:59 AM, Soininen Jonne (Nokia-NET/Helsinki) wrote: > I of course share the worry that the operators will start charging > differently different size end-user allocations. I strongly suspect they will since many ISPs have already incorporated address space charges into their business models. I would imagine ISPs continue to look for any way they can add optional charges to your monthly bill so they can legally advertise low connectivities fees. > However, I feel there > is little we can do about the in the IETF and therefore I would see > that > we should not use too much time on this. I would agree. The IETF hasn't, to my knowledge, been particularly effective in limiting business models. > I think the only practical thing we can do is to advice that the > end-user network will have enough addresses to satisfy its > communication > needs to avoid the introduction of e.g. NAT into IPv6 networks. I would suggest that NATv6 will be created and exist as long as there is a significant (at least perceived) cost to transitioning service providers. 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 Thu Jul 14 13:40:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt7gm-0006fw-L9; Thu, 14 Jul 2005 13:40:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4wb-0005F8-4S for ipv6@megatron.ietf.org; Thu, 14 Jul 2005 10:44:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15154 for ; Thu, 14 Jul 2005 10:44:06 -0400 (EDT) Received: from fj34.ade2.point.ne.jp ([61.117.244.34] helo=nereid.bugest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt5PB-0003xb-1K for ipv6@ietf.org; Thu, 14 Jul 2005 11:13:44 -0400 Received: from bugest.net (nereid.bugest.net [172.16.0.5]) by nereid.bugest.net (Postfix) with ESMTP id A84C13A224; Thu, 14 Jul 2005 23:43:52 +0900 (JST) Message-ID: <42D67A29.9030100@bugest.net> Date: Thu, 14 Jul 2005 23:43:53 +0900 From: Kosuke Ito Organization: IPv6 Promotion Council of Japan / Canon Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: "ipv6@ietf.org" , global-v6@lists.apnic.net References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 14 Jul 2005 13:39:58 -0400 Cc: Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Thomas, Thank you for extending this discussion to the global ML from IETF arena. I have been observing the current discussion on "reviewing the current policies and address allocation practices". Then, I felt that we should resort what a real issue is. Why do we need to change HD-Ratio? Why do we need to change an assignment size? If we change it/them, what do we have in return? Just reducing the pace of address consumption? Do we like to creat SWAMP already? Let me looking back the original intention of implementing HD-Ratio. HD-Ratio was introduced to give ISPs an eligibility to request subsequent allocation automatically in order to achieve one of the goals raised in the policy, such as "reducing overhead". But in some point, RIRs start applying HD-Ratio to decide the "Initial" allocation size based on ISP's existing _IPv4_ customer size, and RIRs and community change the policy itself to fit its practice. After that, initial allocation size gets larger like /21 or /20 than ever before. I believe that there is a twist here. I do not deny the current practice done by RIRs, if RIRs believe that this practice is totally in-line of the global address management to keep in good order. But reviewing this practice could be less impact than considering to change the policy so as to achieve the slowing down the pace of allocation (if it is the goal of this discussion). Regarding the assignment size, when we held JP Open Policy Meeting last week, there are many voices saying that varying assignment size is too much impact on the current commercial service not in its network operation but also for the low-cost routing devices handling /48. According to them, they have already been in service, so they consider that it is not practical to change the assignment policy. But at the same time, ISPs need to make their best effort to achieve the goal of "conservation" still existing in the policy even it is not the first priority. Is it practical to change in other regions? I believe that we can avoid any change in the policy if we look back the goals and refrain from asking as large allocation size and large assignment size as possible just because they can. Nevertheless, if we keep the current pace of allocation, one extrapolation study said that IPv6 might be allocated 50% in 60 years in the worst(?) case. Seems to me, lasting 120 years of IPv6 is long enough, isn't it?? Kosuke JORDI PALET MARTINEZ wrote: > Hi Thomas, > > I totally agree with your appreciations. > > May be one possibility to ensure that this is going to work also with the > RIRs is to hold this document until the RIRs policy changes align to it, and > work pro-actively with them in order to make that happening ASAP ? > > I will suggest a small change to this text (section 2): > "... While that number may > make sense for larger sites, it is hard to imagine a typical home > user requiring so much space. Indeed, the default end site assignment > today is in practice the same for home users and larger businesses." > > For something such as: > "... While that number may > make sense for larger sites, it is hard to imagine, at the time being, a > typical home user requiring so much space, but this can change and we must > be ready and open to that. Indeed, the default end site assignment today is > in practice the same for home users and large businesses. > Moreover, the change in the recommended assignment (from /48 to /56) should > not become a barrier for any customer to get a /48 from the ISP, whenever > the ISP is required for that, with no need for further justifications for > that request." > > > One open question is if this change will impact in the default allocation of > /32 to the LIRs. I mean, should they still keep considering that the > customers will be able to request a /48 and consequently keep allocating the > big prefixes that we have seen until now ? If not, should the big prefixes > already allocated be claimed back ? Yes, I know is a RIR business, but I > think otherwise we clarify it ASAP, it can create a lot of unfairness in the > process with future allocations. > > Moreover, it will be a good suggestion for ISPs to block the remaining /56 > up to the /48 for each customer, in case he ask for it, in order to avoid > renumbering ? If that's the case, there is any meaning for this change > towards the conservation ?. > > Note that there is already some people proposing that the business model for > IPv6 is precisely charging for the addresses, which I believe is totally > broken and a wrong approach. The business will come because there are new > services and applications, for which the ISPs will be able to charge, either > because the service itself or the BW required by the service, or a > combination of both. This will not happen if the addresses aren't available > for free (the applications will never come in that case, and we will end-up > with a NATv6 model). Also some ISPs in AP are already providing only a /64 > and charging for a different "service class" if the customer ask for several > subnets. > > Regards, > Jordi > > (note: I've copied the globa-v6 list as suggested in previous emails from > Thomas) > > > > >>De: Thomas Narten >>Responder a: >>Fecha: Thu, 14 Jul 2005 10:11:19 +0200 >>Para: >>CC: "ipv6@ietf.org" >>Asunto: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >> >>Hi Jordi. >> >> >>>I've read yesterday this document, and I'm basically ok with it, but with >>>two considerations that I think must be worked out it parallel somehow: >>>1) HD-Ratio modification, as it seems to be an integral part of the >>>discussion. >> >>IMO, changing the HD-ratio is a no-brainer, and I suspect that many >>people feel the same way. It's an easy change to make and has minimal >>impact. Indeed, there is already an ARIN proposal to do this: >> >>http://www.arin.net/policy/proposals/2005_5.html >> >>So yes, I expect this will be done and will personally push to see >>this happen. >> >> >>>2) I've the feeling that if we suggest the ISPs to move to a /56, they will >>>then charge the customers (SOHO, end-users) or create to them a lot of >>>troubles to get a bigger prefix when this is needed. >> >>We should be careful NOT to assume that just because something is done >>one way in IPv4, it will be similar in IPv6. >> >>Indeed, I think one of the big cultural changes w.r.t. IPv6 is the >>notion that end sites get subnets (emphasis on plural) where this is >>clearly NOT the norm for IPv4 today. My sense is (from talking to folk >>in the RIR community) is that they all believe this, and that ISPs >>working with IPv6 also get this. So I think we've already changed the >>starting point here. >> >>Also, in IPv4, the existing practice is to give out a single >>address. There are multiple reasons for this, some cultural (i.e., >>status quo). But another point that I think people sometimes forget is >>that the existing protocols and busines practices have been built >>around giving out a single address (rather than a subnet) and such, >>getting a subnet is, in fact, an exception to the norm. As we know, >>exceptions can cost more, i.e., in terms of help desk support, etc. >> >>So even though ISPs in IPv4 do tend to charge more for "more than one >>address", the reasons for that are a bit subtle, and when they say its >>because "more address just cost more", that is really just FUD. In no >>case can the case be made that it is because the extra addresses >>actually "cost more", i.e., in terms of RIR policies. >> >>Again, my sense in the RIR regions is that folk want the RIR policies >>to be very clear that addresses should be available to end sites at >>very low cost (i.e., essentially free), and that the cost of a /48 >>should be the same as a /56 or /64. And with DHCPv6 prefix delegation >>(as the protocol/operational mechanism for achieving this) I think we >>are on track to see the right thing happen. >> >>To ensure that happens, the RIR policies will need to be sure that >>when LIRs need more space from RIRs, the justification should be >>based entirely on whether the existing space is sufficiently utilized >>(based on the HD-ratio) with the metric being completely neutral as to >>whether end sites are getting /48s or /56s. >> >> >>>My feeling is that today we believe that 8 bits for subnetting is >>>enough, but I think will not be the case soon and this barrier will >>>then be again a stopper for enabling innovation. >> >>I think there is a general feeling in the RIR community that folks >>that ask for more than a /56 should generally get it more-or-less by >>asking. I'd welcome help in how to word this. What we don't want is >>folk automatically asking for a /48 "just because they can". In >>practice, a /56 will really be enough for a large percentage of end >>sites, for a long while. Hence, the current "justification" for space >>is probably best expressed in terms of size of a site in terms of >>subnets. That is something objectively measurable and captures the >>sense of whether additional space is really needed. >> >> >>>I know this one is somehow not an IETF business, but we must be >>>worried about that and may be collectively work for the appropriate >>>solution in the appropriate fora. >> >>We simply need to pay attention to what is going on in the RIR >>community, and followup as appropriate. The good news is that my own >>sense (from going to ARIN meetings for 3 years or so, and attending >>the last RIPE meeting) is that the community there largely shares the >>same goals as I'm hearing here. They do understand that IPv6 is >>different than IPv4 and that we need to focus less on conservation >>than IPv4. I think that most of the community is actually quite happy >>about this. >> >> >>>The cost of managing addresses is not a recurrent cost. I mean, it will be >>>ok to charge for a reasonable setup fee if somebody ask for a /48 instead of >>>a /56, but charging 12Euros (or even more) per month per address as some >>>telcos do in EU is a crime. >> >>No. I think there is no justification (in increased $$) for a /48 >>vs. a /56. The RIR policies should be clear about that. That won't >>prevent ISPs from (perhaps) doing this, but they will use weaker >>arguments like "a /48 implies more traffic and therefore more $$". But >>then again maybe not. In practice, with a /56, end sites can generate >>plenty of traffic and ISP charges may end up having to switch to >>something based on actual traffice being carried. >> >>Thomas >> >>-------------------------------------------------------------------- >>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 > > Barcelona 2005 Global IPv6 Summit > Information available at: > http://www.ipv6-es.com > > 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 > -------------------------------------------------------------------- > > -- **********IPv6 Internet Wonderland!************ Kosuke Ito, Master Planning and Steering Group IPv6 Promotion Council of Japan (Visiting Researcher, SFC Lab. KEIO University) Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 Cell:+81-90-4605-4581 mailto: kosuke@v6pc.jp http://www.v6pc.jp/ Lifetime e-mail: kosuke@stanfordalumni.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 Jul 14 15:51:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9k3-00089h-2R; Thu, 14 Jul 2005 15:51:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9il-0007eN-Dk; Thu, 14 Jul 2005 15:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13675; Thu, 14 Jul 2005 15:50:09 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtABJ-0008QD-7a; Thu, 14 Jul 2005 16:19:43 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dt9ic-0006Ck-Jg; Thu, 14 Jul 2005 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, 14 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-icmp-v3-07.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: , Sender: ipv6-bounces@ietf.org 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 : Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta Filename : draft-ietf-ipngwg-icmp-v3-07.txt Pages : 27 Date : 2005-7-14 This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-07.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-ipngwg-icmp-v3-07.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-ipngwg-icmp-v3-07.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: <2005-7-14111704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v3-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-14111704.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 Jul 14 15:52:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9kW-0008Oo-Et; Thu, 14 Jul 2005 15:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9ip-0007gX-7H; Thu, 14 Jul 2005 15:50:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13712; Thu, 14 Jul 2005 15:50:12 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtABK-0008RP-T4; Thu, 14 Jul 2005 16:19:47 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dt9ie-0006HB-7n; Thu, 14 Jul 2005 15:50:04 -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, 14 Jul 2005 15:50:04 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-12.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: , Sender: ipv6-bounces@ietf.org 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 Node Information Queries Author(s) : M. Crawford, B. Haberman Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt Pages : 14 Date : 2005-7-14 This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-12.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-ipngwg-icmp-name-lookups-12.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-ipngwg-icmp-name-lookups-12.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: <2005-7-14145024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-14145024.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 Jul 14 21:21:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEtX-0004zk-QJ; Thu, 14 Jul 2005 21:21:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEtW-0004z8-1m for ipv6@megatron.ietf.org; Thu, 14 Jul 2005 21:21:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27019 for ; Thu, 14 Jul 2005 21:21:36 -0400 (EDT) Received: from [192.20.225.112] (helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtFMD-0001tH-QG for ipv6@ietf.org; Thu, 14 Jul 2005 21:51:19 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id B34EDA7BDE; Thu, 14 Jul 2005 21:21:27 -0400 (EDT) Received: (from fenner@localhost) by windsor.research.att.com (8.11.7p1+Sun/8.8.5) id j6F1LRr19649; Thu, 14 Jul 2005 18:21:27 -0700 (PDT) Message-Id: <200507150121.j6F1LRr19649@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jinmei@isl.rdc.toshiba.co.jp References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.com> <200504031817.j33IHHBS028317@bright.research.att.com> <200504040240.j342ebvl008179@bright.research.att.com> <200504041437.j34EbjkS026424@bright.research.att.com> <200507081616.j68GGmQh026531@bright.research.att.com> Date: Thu, 14 Jul 2005 18:21:26 -0700 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: uri@w3.org, ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >...I didn't understand the proposal >assumed additional requirements for URL/URI parsers, so I didn't >understand its usefulness. **If we can allow that**, I see this can >be useful, while it should be minor usage ... Certainly, it's envisioned to be a small niche, which is why I am not ready to push too hard on it. >..."never force >applications to do any additional work to deal with scopes". I think the push against additional work was really about addresses that look (more or less) the same requiring different handling, e.g., an application would have to know that fec0::1 needed a zone ID but 2002::1 did not. Since my proposal uses an explicitly different syntax, and all addresses expressed using this syntax require the zone ID, I *think* that argument doesn't apply. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 14 22:15:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFed-0000pK-0d; Thu, 14 Jul 2005 22:10:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFea-0000pB-Ow for ipv6@megatron.ietf.org; Thu, 14 Jul 2005 22:10:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29753 for ; Thu, 14 Jul 2005 22:10:14 -0400 (EDT) Received: from mail.syce.net ([192.16.178.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtG7I-0003Ht-LR for ipv6@ietf.org; Thu, 14 Jul 2005 22:39:58 -0400 Received: from localhost (mail.syce.net [IPv6:2001:218:4fd::25]) by mail.syce.net (8.12.11/8.12.11) with ESMTP/inet6 id j6F29vxr078442; Fri, 15 Jul 2005 11:09:57 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Fri, 15 Jul 2005 11:09:48 +0900 (JST) Message-Id: <20050715.110948.294707638.fujisaki@syce.net> To: ipv6@ietf.org, global-v6@lists.apnic.net From: (Tomohiro -INSTALLER- Fujisaki) In-Reply-To: <42D67A29.9030100@bugest.net> References: <42D67A29.9030100@bugest.net> X-Mailer: Mew version 4.2 on XEmacs 21.4.15 (Security Through Obscurity) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org | Regarding the assignment size, when we held JP Open Policy | Meeting last week, there are many voices saying that | varying assignment size is too much impact on the current | commercial service not in its network operation but also | for the low-cost routing devices handling /48. | According to them, they have already been in service, | so they consider that it is not practical to change the | assignment policy. But at the same time, ISPs need to make | their best effort to achieve the goal of "conservation" still | existing in the policy even it is not the first priority. Actually, some providers have already assigned /48 based on current recommendation in their commercial service, and as Kosuke said, it will have a large impact to change the assignemnt size. I've looked up the assignemnt size used in JP regison: http://www.apnic.net/meetings/18/docs/sigs/policy/policy-pres-tomohiro-ipv6-endusers.pdf This is slightly dated information, and recently, at least one provider has been starting commercial IPv6 services with /48 assignment. This service is targeted on residential users. | Is it practical to change in other regions? I also would like to know about this. -- Tomohiro Fujisaki -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 15 06:16:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNEp-0008GK-VT; Fri, 15 Jul 2005 06:16:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNEn-0008GF-U0 for ipv6@megatron.ietf.org; Fri, 15 Jul 2005 06:16:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21120 for ; Fri, 15 Jul 2005 06:16:06 -0400 (EDT) Received: from mail.vnnic.net.vn ([203.162.57.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtNhb-0001vm-6X for ipv6@ietf.org; Fri, 15 Jul 2005 06:45:55 -0400 Received: (from NGUYENTHUTHUY [203.119.9.16]) by mail.vnnic.net.vn (SMSSMTP 4.1.0.19) with SMTP id M2005071517092127623 for ; Fri, 15 Jul 2005 17:09:21 +0700 Message-ID: <027201c58926$2d80de70$100977cb@NGUYENTHUTHUY> From: "Thu Thuy" To: Date: Fri, 15 Jul 2005 17:15:51 +0700 MIME-Version: 1.0 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: 0.8 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: ipv6-enabled software X-BeenThere: ipv6@ietf.org 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="===============0380519725==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0380519725== Content-Type: multipart/alternative; boundary="----=_NextPart_000_026F_01C58960.D9C7E8B0" This is a multi-part message in MIME format. ------=_NextPart_000_026F_01C58960.D9C7E8B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, all I'm in my way to investigate on ipv6 trial and implementation. Now i'm = stucking with a quite big question on ipv6-enabled software.=20 As i saw, ipv6 web services is entirely implemented in almost such large = ipv6 research projects as KAME, WIDE, GEANT... In Japan, some ISPs offer = ipv6 web hosting to their customers. Many websites support native ipv6 = such as RIPE, APNIC... Could you pls show me what kind of webserver software be used in = above-mentioned projects and organisations to fully implement ipv6 web = service to users. Thanks. ------=_NextPart_000_026F_01C58960.D9C7E8B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, all
 
I'm in my way to investigate on ipv6 = trial and=20 implementation. Now i'm stucking with a quite big question on = ipv6-enabled=20 software.
 
As i saw, ipv6 web services = is entirely=20 implemented in almost such large ipv6 research projects as = KAME, WIDE,=20 GEANT... In Japan, some ISPs offer ipv6 web hosting to their customers. = Many=20 websites support native ipv6 such as RIPE, APNIC...
 
Could you pls show me what kind of = webserver=20 software be used in above-mentioned projects and organisations to = fully=20 implement ipv6 web service to users.
 
Thanks.
------=_NextPart_000_026F_01C58960.D9C7E8B0-- --===============0380519725== 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 -------------------------------------------------------------------- --===============0380519725==-- From ipv6-bounces@ietf.org Fri Jul 15 06:22:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNKU-0001XN-Ez; Fri, 15 Jul 2005 06:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNKS-0001X4-5d for ipv6@megatron.ietf.org; Fri, 15 Jul 2005 06:22:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21474 for ; Fri, 15 Jul 2005 06:21:57 -0400 (EDT) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtNnE-00028X-Sg for ipv6@ietf.org; Fri, 15 Jul 2005 06:51:45 -0400 Received: from [10.10.10.100] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001148661.msg for ; Fri, 15 Jul 2005 12:22:57 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 15 Jul 2005 12:21:34 +0200 From: JORDI PALET MARTINEZ To: "ipv6@ietf.org" Message-ID: In-Reply-To: <027201c58926$2d80de70$100977cb@NGUYENTHUTHUY> Mime-version: 1.0 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 15 Jul 2005 12:22:57 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: Re: ipv6-enabled software 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: , Content-Type: multipart/mixed; boundary="===============1460485942==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >Este mensaje tiene formato MIME. Al no reconocer su lector de correo este formato, puede que todo o parte del mensaje resulte ilegible. --===============1460485942== Content-type: multipart/alternative; boundary="B_3204274898_483361" >Este mensaje tiene formato MIME. Al no reconocer su lector de correo este formato, puede que todo o parte del mensaje resulte ilegible. --B_3204274898_483361 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, This is probably not the best list for this, but I can tell that Apache and IIS, among others, support it. You can take a look at http://www.ipv6tf.org for more information and links. Regards, Jordi De: Thu Thuy Responder a: Fecha: Fri, 15 Jul 2005 17:15:51 +0700 Para: Asunto: ipv6-enabled software Hi, all I'm in my way to investigate on ipv6 trial and implementation. Now i'm stucking with a quite big question on ipv6-enabled software. As i saw, ipv6 web services is entirely implemented in almost such large ipv6 research projects as KAME, WIDE, GEANT... In Japan, some ISPs offer ipv6 web hosting to their customers. Many websites support native ipv6 such as RIPE, APNIC... Could you pls show me what kind of webserver software be used in above-mentioned projects and organisations to fully implement ipv6 web service to users. Thanks. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --B_3204274898_483361 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: ipv6-enabled software Hi,
This is probably not the best list for this, but I can tell that Apache and= IIS, among others, support it.

You can take a look at http://www.ipv6tf.or= g for more information and links.

Regards,
Jordi




De: Thu Thuy <thuthuy@vnnic= .net.vn>
Responder a: <ipv6-bounces@ietf.org>
Fecha: Fri, 15 Jul 2005 17:15:51 +0700
Para: <ipv6@ietf.org>
Asunto: ipv6-enabled software

Hi, all
I'm in my way to investigate on ipv6 trial and im= plementation. Now i'm stucking with a quite big question on ipv6-enabled sof= tware.

As i saw, ipv6 web services is entirely implement= ed in almost such large ipv6 research projects as KAME, WIDE, GEANT... In Ja= pan, some ISPs offer ipv6 web hosting to their customers. Many websites supp= ort native ipv6 such as RIPE, APNIC...
Could you pls show me what kind of webserver soft= ware be used in above-mentioned projects and organisations to fully implemen= t ipv6 web service to users.
Thanks.

---------------------= -----------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
 --B_3204274898_483361-- --===============1460485942== 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 -------------------------------------------------------------------- --===============1460485942==-- From ipv6-bounces@ietf.org Fri Jul 15 06:40:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNcD-0005oj-N7; Fri, 15 Jul 2005 06:40:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNcB-0005o6-Fe for ipv6@megatron.ietf.org; Fri, 15 Jul 2005 06:40:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23174 for ; Fri, 15 Jul 2005 06:40:16 -0400 (EDT) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtO4w-0002ve-4U for ipv6@ietf.org; Fri, 15 Jul 2005 07:10:05 -0400 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 3755A552D; Fri, 15 Jul 2005 12:39:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 3176654E6; Fri, 15 Jul 2005 12:39:56 +0200 (CEST) Date: Fri, 15 Jul 2005 12:39:56 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Thu Thuy In-Reply-To: <027201c58926$2d80de70$100977cb@NGUYENTHUTHUY> Message-ID: <20050715123352.F24351@mignon.ki.iif.hu> References: <027201c58926$2d80de70$100977cb@NGUYENTHUTHUY> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipv6@ietf.org Subject: Re: ipv6-enabled software X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, Have a look at: http://www.deepspace6.net/docs/ipv6_status_page_apps.html#id2877777 or http://ipv6.niif.hu/ipv6_apps Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Fri, 15 Jul 2005, Thu Thuy wrote: > Hi, all > > I'm in my way to investigate on ipv6 trial and implementation. Now i'm > stucking with a quite big question on ipv6-enabled software. > > As i saw, ipv6 web services is entirely implemented in almost such large > ipv6 research projects as KAME, WIDE, GEANT... In Japan, some ISPs offer > ipv6 web hosting to their customers. Many websites support native ipv6 > such as RIPE, APNIC... > > Could you pls show me what kind of webserver software be used in > above-mentioned projects and organisations to fully implement ipv6 web > service to users. > > Thanks. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 15 07:13:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtO7r-00083h-8a; Fri, 15 Jul 2005 07:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtO7p-00081w-N3 for ipv6@megatron.ietf.org; Fri, 15 Jul 2005 07:13:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24984 for ; Fri, 15 Jul 2005 07:12:58 -0400 (EDT) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtOac-00042z-5v for ipv6@ietf.org; Fri, 15 Jul 2005 07:42:47 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Fri, 15 Jul 2005 11:12:58 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw12c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Fri, 15 Jul 2005 11:12:46 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5892E.1A61E07E" Date: Fri, 15 Jul 2005 06:12:35 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9767A4@NAEAMILLEX05VA.nadsusea.nads.navy.mil> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-pashby-ipv6-detecting-spoofing-00.txt Thread-Index: AcWIyJVKoCXmLJbFQbG4crzTJQXYigAZXZ3g From: "Pashby, Ronald W CTR NSWCDD-B35" To: X-OriginalArrivalTime: 15 Jul 2005 11:12:35.0620 (UTC) FILETIME=[1A82AE40:01C5892E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Subject: FW: I-D ACTION:draft-pashby-ipv6-detecting-spoofing-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5892E.1A61E07E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, July 14, 2005 18:50 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-pashby-ipv6-detecting-spoofing-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Detection of IPv6 Neighbor Discovery and Host Redirection = Spoofing Author(s) : R. Pashby Filename : draft-pashby-ipv6-detecting-spoofing-00.txt Pages :=20 Date : 2005-7-14 =09 The purpose of this draft is to provide a method to detect=20 exploitation of inherent vulnerabilities in the Neighbor Discovery=20 processes. There are two well documented vulnerabilities in the basic IPv6=20 architecture: Neighbor Discover spoofing and Host Redirection. =20 There already exists the SeND RFC [send] that addresses=20 authenticating these interactions. Certain networks may choose not=20 to uses (or cannot use) SeND, for instance, networks that use DHCP=20 or statically assigned addresses. There is an underlying security principle that says, ^If you can=20 block a attack do it. If you cannot block it, detect it. Even if=20 you can block it, detect it.^ This proposal outlines simple=20 modifications to the basic protocols to allow for easily detecting=20 these attacks. Through proactive systems, once an attack is=20 detected it could easily provide blocking by isolating the=20 attacking host via Access Control Lists (ACLs) or disabling ports. The basic method proposed is to force packets used in these attacks=20 to be multicast to the attacked nodes Solicited Node Multicast=20 group, thus allowing a security device to detect when it is=20 occurring. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pashby-ipv6-detecting-spoofing-= 00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-pashby-ipv6-detecting-spoofing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-pashby-ipv6-detecting-spoofing-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C5892E.1A61E07E Content-Type: application/octet-stream; name="ATT234967.TXT" Content-Description: ATT234967.TXT Content-Disposition: attachment; filename="ATT234967.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC10eXBlOiBtZXNz YWdlL2V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwtc2VydmVyIjsNCglzZXJ2ZXI9 Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCkNvbnRlbnQt SUQ6IDwyMDA1LTctMTQxNTQwMDcuSS1EQGlldGYub3JnPg0KDQpFTkNPRElORyBtaW1lDQpGSUxF IC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGFzaGJ5LWlwdjYtZGV0ZWN0aW5nLXNwb29maW5nLTAw LnR4dA0K ------_=_NextPart_001_01C5892E.1A61E07E Content-Type: application/octet-stream; name="draft-pashby-ipv6-detecting-spoofing-00.URL" Content-Description: draft-pashby-ipv6-detecting-spoofing-00.URL Content-Disposition: attachment; filename="draft-pashby-ipv6-detecting-spoofing-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1wYXNoYnktaXB2Ni1kZXRlY3Rpbmctc3Bvb2ZpbmctMDAudHh0DQo= ------_=_NextPart_001_01C5892E.1A61E07E Content-Type: text/plain; name="ATT234967.txt" Content-Description: ATT234967.txt Content-Disposition: attachment; filename="ATT234967.txt" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C5892E.1A61E07E 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_01C5892E.1A61E07E-- From ipv6-bounces@ietf.org Fri Jul 15 07:14:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtO8l-0008Fp-V1; Fri, 15 Jul 2005 07:13:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtO8k-0008Fk-0O for ipv6@megatron.ietf.org; Fri, 15 Jul 2005 07:13:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25028 for ; Fri, 15 Jul 2005 07:13:54 -0400 (EDT) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtObX-00044r-SX for ipv6@ietf.org; Fri, 15 Jul 2005 07:43:44 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Fri, 15 Jul 2005 11:13:56 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Fri, 15 Jul 2005 11:13:45 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5892E.437D9B0C" Date: Fri, 15 Jul 2005 06:13:44 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9767A5@NAEAMILLEX05VA.nadsusea.nads.navy.mil> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcWIx7+My5KLF6rNQ5i3ieuaHIsg5AAZm7Eg From: "Pashby, Ronald W CTR NSWCDD-B35" To: X-OriginalArrivalTime: 15 Jul 2005 11:13:44.0509 (UTC) FILETIME=[43924ED0:01C5892E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: FW: I-D ACTION:draft-pashby-ipv6-network-discovery-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5892E.437D9B0C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, July 14, 2005 18:50 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-pashby-ipv6-network-discovery-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Changes Needed to Allow for IPv6 Network Discovery Author(s) : R. Pashby Filename : draft-pashby-ipv6-network-discovery-00.txt Pages :=20 Date : 2005-7-14 =09 The purpose of the draft is to provide mechanisms to discover all=20 nodes and addresses on an IPv6 network. Network discovery is a key to network management and network=20 security. In IPv4 the most effective way to discover what devices=20 were attached to the network was to walk the entire network address=20 space. While this was easily done in IPv4, it is impossible in=20 IPv6, due to the large range of addresses on a network. Currently=20 there is no effective way to discover the nodes on an IPv6 network.=20 This document describes the changes that need to be made to allow=20 for discovering nodes on an IPv6 network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pashby-ipv6-network-discovery-0= 0.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-pashby-ipv6-network-discovery-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-pashby-ipv6-network-discovery-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C5892E.437D9B0C Content-Type: application/octet-stream; name="ATT234952.TXT" Content-Description: ATT234952.TXT Content-Disposition: attachment; filename="ATT234952.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC10eXBlOiBtZXNz YWdlL2V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwtc2VydmVyIjsNCglzZXJ2ZXI9 Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCkNvbnRlbnQt SUQ6IDwyMDA1LTctMTQxNTQyMjYuSS1EQGlldGYub3JnPg0KDQpFTkNPRElORyBtaW1lDQpGSUxF IC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGFzaGJ5LWlwdjYtbmV0d29yay1kaXNjb3ZlcnktMDAu dHh0DQo= ------_=_NextPart_001_01C5892E.437D9B0C Content-Type: application/octet-stream; name="draft-pashby-ipv6-network-discovery-00.URL" Content-Description: draft-pashby-ipv6-network-discovery-00.URL Content-Disposition: attachment; filename="draft-pashby-ipv6-network-discovery-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1wYXNoYnktaXB2Ni1uZXR3b3JrLWRpc2NvdmVyeS0wMC50eHQNCg== ------_=_NextPart_001_01C5892E.437D9B0C Content-Type: text/plain; name="ATT234953.txt" Content-Description: ATT234953.txt Content-Disposition: attachment; filename="ATT234953.txt" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C5892E.437D9B0C 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_01C5892E.437D9B0C-- From ipv6-bounces@ietf.org Fri Jul 15 14:40:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtV6o-0007Fr-3e; Fri, 15 Jul 2005 14:40:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtV6l-0007FS-Ne for ipv6@megatron.ietf.org; Fri, 15 Jul 2005 14:40:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04630 for ; Fri, 15 Jul 2005 14:40:21 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtVZb-0005Hc-BE for ipv6@ietf.org; Fri, 15 Jul 2005 15:10:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6FI8Tv20025; Fri, 15 Jul 2005 11:08:29 -0700 X-mProtect: <200507151808> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp160188.americas.nokia.com (10.241.160.188, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdn7NR6K; Fri, 15 Jul 2005 11:08:28 PDT Message-Id: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 11:39:55 -0700 To: IPv6 WG From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This starts a two week IPv6 working group last call on advancing: Title : IPv6 Node Information Queries Author(s) : M. Crawford, B. Haberman Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt Pages : 14 Date : 2005-7-14 to Experimental. Please send substantive comments to the IPv6 mailing list. Editorial comments can be sent to the authors. This last call will end on July 29, 2005. Regards, Bob & Brian IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 15 15:50:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWCT-0005x6-Tw; Fri, 15 Jul 2005 15:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWCB-0005oP-Hn; Fri, 15 Jul 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10828; Fri, 15 Jul 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWf2-0007oc-Kh; Fri, 15 Jul 2005 16:19:53 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DtWC9-0001qY-Ef; Fri, 15 Jul 2005 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, 15 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ndproxy-03.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: , Sender: ipv6-bounces@ietf.org 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 : Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-03.txt Pages : 20 Date : 2005-7-15 Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. The behavior of one common type of IPv4 ARP Proxy deployed today is documented herein for informational purposes, but this document concentrates on describing similar behavior for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-03.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-ndproxy-03.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-ndproxy-03.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: <2005-7-15112402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ndproxy-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ndproxy-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-15112402.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 Jul 15 18:19:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYX6-0000Lj-T6; Fri, 15 Jul 2005 18:19:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYX5-0000LU-4N for ipv6@megatron.ietf.org; Fri, 15 Jul 2005 18:19:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00601 for ; Fri, 15 Jul 2005 18:19:43 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYzx-0000V1-Py for ipv6@ietf.org; Fri, 15 Jul 2005 18:49:39 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6FLltk32007 for ; Fri, 15 Jul 2005 14:47:55 -0700 X-mProtect: <200507152147> Nokia Silicon Valley Messaging Protection Received: from danira-pool049175.americas.nokia.com (10.241.49.175, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdswOzeC; Fri, 15 Jul 2005 14:47:54 PDT Message-Id: <6.2.1.2.2.20050715151550.02aa3a20@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 15:18:40 -0700 To: IPv6 WG From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This starts a one week IPv6 working group last call on advancing Title : Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-03.txt Pages : 20 Date : 2005-7-15 to Experimental. Please send substantive comments to the IPv6 mailing list. Editorial comments can be sent to the authors. This last call will end on July 22, 2005. Regards, Bob & Brian IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 15 20:40:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtajR-0005Go-1H; Fri, 15 Jul 2005 20:40:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtajN-0005Dp-0a for ipv6@megatron.ietf.org; Fri, 15 Jul 2005 20:40:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10109 for ; Fri, 15 Jul 2005 20:40:34 -0400 (EDT) Message-Id: <200507160040.UAA10109@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtbCH-0004k9-JR for ipv6@ietf.org; Fri, 15 Jul 2005 21:10:30 -0400 Received: from eaglet (127.0.0.1:3806) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 15 Jul 2005 17:40:17 -0700 From: "Tony Hain" To: "'Thomas Narten'" , Date: Fri, 15 Jul 2005 17:40:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200507132144.j6DLi2r5006080@cichlid.raleigh.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWH9HhMZpiT59+UQyi1bVMJx7eMKgBqA/yA X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Cc: Subject: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I said part of this on the ARIN PPML list but thought it should be repeated here. A /64 allocation never makes any sense. The claims about a PDA only needing one assume that it will never be dropped into a cradle of a vehicle suddenly enabling various subnets (freight environmental or inventory monitor, dispatch service) to reach out or be reached with independent access controls. A /64 puts the carrier in the position of telling the customer they can't build anything more than a single lan, where a /60 removes that limitation with effectively the same impact on space utilization. We bumped into another version of this when thinking through some of the issues with cable. The MSO's appear to be focusing around a prefix being the unit of allocation to a customer. All well and good until we get the 'a /64 is more than enough space' discussion. The issue crystallized when the discussion included a separate subnet for cable devices in the home to communicate locally. Since the MSO has bought into the concept of a prefix maps to a customer, having independent /64's breaks the allocation and management model. The conservation mindset clashes with the simplified management mindset and documents with wording like this are not helping. This draft really needs to remove the discussion about a /64 being appropriate for anything from an allocation perspective. There is no serious technical need for the draft to begin with, but if it exists it should point out that a /60 is the longest prefix that allows customers to build networks with multiple links (specifically technologies that don't bridge) and maps cleanly onto the reverse delegation name tree. Tony > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Wednesday, July 13, 2005 2:44 PM > To: ipv6@ietf.org > Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > Here's an ID for consideration by the IPv6 WG. > > Background: > > Discussion on the more general topic took place at the April ARIN and > May RIPE meetings. A good summary of those presentations can be found > at: > > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary- > wed-ipv6-roundtable-report.pdf > > A more general discussion of the overall topic of IPv6 address > allocation considerations (the /48 boundary topic is just one piece of > a larger puzzle) can be found at: > > http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6- > considerations-00.txt > > Thomas > > ------- Forwarded Message > > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Date: Tue, 12 Jul 2005 15:50:03 -0400 > Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > Reply-To: internet-drafts@ietf.org > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IPv6 Address Allocation to End Sites > Author(s) : T. Narten, et al. > Filename : draft-narten-ipv6-3177bis-48boundary-00.txt > Pages : 8 > Date : 2005-7-12 > > This document revisits the IAB/IESG recommendations on the assignment > of IPv6 address space to end sites. Specifically, it indicates that > changing the default end-site assignment for typical home and SOHO > sites from /48 to /56 is consistent with the goals of IPv6 and RFC > 3177. Although it is for the RIR community to make adjustments to the > IPv6 address space allocation and end site assignment policies, the > IETF community would be comfortable with RIRs changing the default > assignment size to /56 for smaller end sites. This document obsoletes > RFC 3177 and reclassifies it as historic. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary- > 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-narten-ipv6-3177bis-48boundary-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-narten-ipv6-3177bis-48boundary-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: <2005-7-12130012.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-narten-ipv6-3177bis-48boundary-00.txt"; > site="ftp.ietf.org"; access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <2005-7-12130012.I-D@ietf.org> > > > --OtherAccess-- > > --NextPart > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > --NextPart-- > > ------- End of Forwarded Message > > -------------------------------------------------------------------- > 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 Sat Jul 16 08:20:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlen-0001oX-Cg; Sat, 16 Jul 2005 08:20:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlel-0001oS-86 for ipv6@megatron.ietf.org; Sat, 16 Jul 2005 08:20:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11497 for ; Sat, 16 Jul 2005 08:20:31 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtm7k-00050n-5r for ipv6@ietf.org; Sat, 16 Jul 2005 08:50:32 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j6GCKJ9R015874 for ; Sat, 16 Jul 2005 08:20:19 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6GCKJSw239366 for ; Sat, 16 Jul 2005 08:20:19 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j6GCKJKU021810 for ; Sat, 16 Jul 2005 08:20:19 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-241-250.mts.ibm.com [9.65.241.250]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j6GCKHAV021736; Sat, 16 Jul 2005 08:20:18 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j6GCKFXD004875; Sat, 16 Jul 2005 14:20:16 +0200 Message-Id: <200507161220.j6GCKFXD004875@cichlid.raleigh.ibm.com> To: Kosuke Ito In-Reply-To: Message from Kosuke Ito of "Thu, 14 Jul 2005 23:43:53 +0900." <42D67A29.9030100@bugest.net> Date: Sat, 16 Jul 2005 14:20:15 +0200 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: "ipv6@ietf.org" , global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Ito-san, You raise some good questions. > I have been observing the current discussion on "reviewing > the current policies and address allocation practices". > Then, I felt that we should resort what a real issue is. > Why do we need to change HD-Ratio? To ensure that we really have plenty of IPv6 addresses to last us 100+ years. Consider IPv4. Have we already run out? Some say effectively yes, because now that we see that we will run out, addressing policy has changed (to increase conservation) and it has become harder to get them. Hence, we've been forced to change our behavior in response to a decrease in the supply. I think we'd all agree that it is harder to get IPv4 address space today than we ever want it to be for IPv6. If we actually end up using up a significant fraction of the IPv6 address space in the next 50 years (even if there is then still plenty left), we may find ourselves forced to change our consumption behavior in anticipation of possibly running out. In order for there really to be "plenty of addresses", we really want there to never be any serious concern that we will run out. draft-narten-iana-rir-ipv6-considerations-00.txt tries to lay out the rational for changing the policies to be more conservative. See also http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf > Why do we need to change an assignment size? So that we don't ever finding ourselves in the postion of saying "things sure would be better now had we only been a bit more conservative from the start". It's easy to make policies more liberal later (if necessary/desireable). It will be much more difficult to go from a more liberal policy to an more conservative one later (look at the IPv4 situation today). > If we change it/them, what do we have in return? Increased confidence that there will be plenty of IPv6 addresses for at least a hundred years. > Just reducing the pace of address consumption? Yes, but I would phrase it differently. I'd argue it's more the case to say "reduce the pace of address wastage". I don't think anyone wants to prevent people from getting address space that they will actually use. But as it stands now, we are handing out a lot of address space that even ISPs who are getting that much are suggesting is way more than they really need. > Do we like to creat SWAMP already? The swamp is more about long prefixes that don't aggregate, leading to many prefixes in the routing table. Changing the amount of space we allocate to end sites doesn't change this. > Let me looking back the original intention of implementing > HD-Ratio. HD-Ratio was introduced to give ISPs an eligibility > to request subsequent allocation automatically in order > to achieve one of the goals raised in the policy, such as > "reducing overhead". > But in some point, RIRs start applying HD-Ratio to decide > the "Initial" allocation size based on ISP's existing _IPv4_ > customer size, and RIRs and community change the policy > itself to fit its practice. After that, initial allocation > size gets larger like /21 or /20 than ever before. I believe > that there is a twist here. I do not deny the current > practice done by RIRs, if RIRs believe that this practice > is totally in-line of the global address management to keep > in good order. > But reviewing this practice could be less impact than > considering to change the policy so as to achieve the > slowing down the pace of allocation (if it is the goal > of this discussion). An interesting point. The large allocations we are seeing now do stem from ISPs using their existing IPv4 infrastructure and applying the HD ratio to that. I think that is consistent though with the original policy. I.e., it said: 4.4. Consideration of IPv4 Infrastructure Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure. > Regarding the assignment size, when we held JP Open Policy > Meeting last week, there are many voices saying that > varying assignment size is too much impact on the current > commercial service not in its network operation but also > for the low-cost routing devices handling /48. Can someone explain why this is? What is the issue? > According to them, they have already been in service, > so they consider that it is not practical to change the > assignment policy. But at the same time, ISPs need to make > their best effort to achieve the goal of "conservation" still > existing in the policy even it is not the first priority. > Is it practical to change in other regions? Personally, I think we probably don't need to do anything about the existing allocations. So this would be for future allocations. (Then again, if DHCP and prefix delegation is being used, how hard would this be to change for existing home users?) Are there implementations or deployment scenarios that _assume_ that they will get a /48? If so, in what ways are they using the 16 subnet bits? > I believe that we can avoid any change in the policy > if we look back the goals and refrain from asking as > large allocation size and large assignment size as > possible just because they can. To stop the large allocations, changing the HD ratio metric will save only about 3 bits. That is, it will give save us about an order of magnitude more space. But changing the /48 default to /56 produces two orders of magnitude more in savings. Cutting the projected consumption by three orders of magnitude is a huge amount of savings. One order is quite a bit less. > Nevertheless, if we keep the current pace of allocation, one > extrapolation study said that IPv6 might be allocated 50% in 60 > years in the worst(?) case. Seems to me, lasting 120 years of IPv6 > is long enough, isn't it?? The main issue is that there is inherent uncertainty in projections. We really don't know how many devices will be connected to the network in 50 years. Our projections are at best estimates and may be closer to guesses. Given that the most important problem IPv6 is supposed to solve is the shortage of addresses, we really don't want to get this part wrong. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jul 16 16:40:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DttSz-0000Vt-Eq; Sat, 16 Jul 2005 16:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DttSs-0000Ve-CY for ipv6@megatron.ietf.org; Sat, 16 Jul 2005 16:40:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00373 for ; Sat, 16 Jul 2005 16:40:48 -0400 (EDT) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dttvv-0000Bp-BD for ipv6@ietf.org; Sat, 16 Jul 2005 17:10:54 -0400 Received: from [10.10.10.100] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001150483.msg for ; Sat, 16 Jul 2005 22:40:49 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 16 Jul 2005 22:39:25 +0200 From: JORDI PALET MARTINEZ To: , "ipv6@ietf.org" Message-ID: In-Reply-To: <200507160040.UAA10109@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es 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 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Processed: consulintel.es, Sat, 16 Jul 2005 22:40:49 +0200 X-MDAV-Processed: consulintel.es, Sat, 16 Jul 2005 22:40:52 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: 7bit Cc: Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I tend to agree with this. I see situations for assigning a /128 when a unique device is connected, which is not going to route anything else, but once it has other interfaces (which is the most common case and will become more and more often) ... Regards, Jordi > De: Tony Hain > Responder a: > Fecha: Fri, 15 Jul 2005 17:40:24 -0700 > Para: 'Thomas Narten' , > Asunto: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > I said part of this on the ARIN PPML list but thought it should be repeated > here. > > A /64 allocation never makes any sense. The claims about a PDA only needing > one assume that it will never be dropped into a cradle of a vehicle suddenly > enabling various subnets (freight environmental or inventory monitor, > dispatch service) to reach out or be reached with independent access > controls. A /64 puts the carrier in the position of telling the customer > they can't build anything more than a single lan, where a /60 removes that > limitation with effectively the same impact on space utilization. > > We bumped into another version of this when thinking through some of the > issues with cable. The MSO's appear to be focusing around a prefix being the > unit of allocation to a customer. All well and good until we get the 'a /64 > is more than enough space' discussion. The issue crystallized when the > discussion included a separate subnet for cable devices in the home to > communicate locally. Since the MSO has bought into the concept of a prefix > maps to a customer, having independent /64's breaks the allocation and > management model. The conservation mindset clashes with the simplified > management mindset and documents with wording like this are not helping. > > This draft really needs to remove the discussion about a /64 being > appropriate for anything from an allocation perspective. There is no serious > technical need for the draft to begin with, but if it exists it should point > out that a /60 is the longest prefix that allows customers to build networks > with multiple links (specifically technologies that don't bridge) and maps > cleanly onto the reverse delegation name tree. > > Tony > > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Thomas Narten >> Sent: Wednesday, July 13, 2005 2:44 PM >> To: ipv6@ietf.org >> Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >> >> Here's an ID for consideration by the IPv6 WG. >> >> Background: >> >> Discussion on the more general topic took place at the April ARIN and >> May RIPE meetings. A good summary of those presentations can be found >> at: >> >> http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary- >> wed-ipv6-roundtable-report.pdf >> >> A more general discussion of the overall topic of IPv6 address >> allocation considerations (the /48 boundary topic is just one piece of >> a larger puzzle) can be found at: >> >> http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6- >> considerations-00.txt >> >> Thomas >> >> ------- Forwarded Message >> >> From: Internet-Drafts@ietf.org >> To: i-d-announce@ietf.org >> Date: Tue, 12 Jul 2005 15:50:03 -0400 >> Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >> Reply-To: internet-drafts@ietf.org >> >> --NextPart >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : IPv6 Address Allocation to End Sites >> Author(s) : T. Narten, et al. >> Filename : draft-narten-ipv6-3177bis-48boundary-00.txt >> Pages : 8 >> Date : 2005-7-12 >> >> This document revisits the IAB/IESG recommendations on the assignment >> of IPv6 address space to end sites. Specifically, it indicates that >> changing the default end-site assignment for typical home and SOHO >> sites from /48 to /56 is consistent with the goals of IPv6 and RFC >> 3177. Although it is for the RIR community to make adjustments to the >> IPv6 address space allocation and end site assignment policies, the >> IETF community would be comfortable with RIRs changing the default >> assignment size to /56 for smaller end sites. This document obsoletes >> RFC 3177 and reclassifies it as historic. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary- >> 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-narten-ipv6-3177bis-48boundary-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-narten-ipv6-3177bis-48boundary-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: <2005-7-12130012.I-D@ietf.org> >> >> ENCODING mime >> FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt >> >> --OtherAccess >> Content-Type: Message/External-body; >> name="draft-narten-ipv6-3177bis-48boundary-00.txt"; >> site="ftp.ietf.org"; access-type="anon-ftp"; >> directory="internet-drafts" >> >> Content-Type: text/plain >> Content-ID: <2005-7-12130012.I-D@ietf.org> >> >> >> --OtherAccess-- >> >> --NextPart >> Content-Type: text/plain; charset="us-ascii" >> MIME-Version: 1.0 >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> --NextPart-- >> >> ------- End of Forwarded Message >> >> -------------------------------------------------------------------- >> 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 Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com 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 Sun Jul 17 00:00:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du0Ke-0006hr-Jk; Sun, 17 Jul 2005 00:00:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du0Kc-0006hm-Km for ipv6@megatron.ietf.org; Sun, 17 Jul 2005 00:00:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18719 for ; Sun, 17 Jul 2005 00:00:43 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du0nl-0004gU-Rj for ipv6@ietf.org; Sun, 17 Jul 2005 00:30:54 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id D07B73FC for ; Sun, 17 Jul 2005 00:00:26 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 17 Jul 2005 00:00:26 -0400 Message-Id: <20050717040026.D07B73FC@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 9.30% | 4 | 14.37% | 40034 | jordi.palet@consulintel.es 9.30% | 4 | 11.54% | 32136 | brian@innovationslab.net 11.63% | 5 | 8.13% | 22646 | elwynd@dial.pipex.com 6.98% | 3 | 9.33% | 25974 | narten@us.ibm.com 6.98% | 3 | 6.66% | 18546 | internet-drafts@ietf.org 6.98% | 3 | 3.80% | 10595 | bob.hinden@nokia.com 4.65% | 2 | 6.06% | 16890 | ronald.pashby.ctr@navy.mil 4.65% | 2 | 3.38% | 9421 | h.soliman@flarion.com 4.65% | 2 | 3.15% | 8766 | stig.venaas@uninett.no 2.33% | 1 | 5.38% | 14989 | kosuke@bugest.net 2.33% | 1 | 3.43% | 9541 | alh-ietf@tndh.net 2.33% | 1 | 3.42% | 9537 | jonne.soininen@nokia.com 2.33% | 1 | 2.76% | 7679 | pekkas@netcore.fi 2.33% | 1 | 2.56% | 7132 | @ 2.33% | 1 | 2.16% | 6030 | jinmei@isl.rdc.toshiba.co.jp 2.33% | 1 | 1.97% | 5488 | thuthuy@vnnic.net.vn 2.33% | 1 | 1.73% | 4816 | fred.l.templin@boeing.com 2.33% | 1 | 1.59% | 4421 | fernando@gont.com.ar 2.33% | 1 | 1.56% | 4335 | fenner@research.att.com 2.33% | 1 | 1.49% | 4161 | david.conrad@nominum.com 2.33% | 1 | 1.46% | 4067 | fujisaki@syce.net 2.33% | 1 | 1.44% | 3998 | brc@zurich.ibm.com 2.33% | 1 | 1.33% | 3698 | mohacsi@niif.hu 2.33% | 1 | 1.31% | 3637 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 43 |100.00% | 278537 | 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 ipv6-bounces@ietf.org Sun Jul 17 07:26:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du7IB-0004yD-J8; Sun, 17 Jul 2005 07:26:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du7I9-0004y8-8I for ipv6@megatron.ietf.org; Sun, 17 Jul 2005 07:26:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27770 for ; Sun, 17 Jul 2005 07:26:38 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du7lJ-0007r4-Ph for ipv6@ietf.org; Sun, 17 Jul 2005 07:56:50 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7C0865E30E; Sun, 17 Jul 2005 13:26:07 +0200 (CEST) Received: from [163.117.203.29] (unknown [163.117.203.29]) by smtp01.uc3m.es (Postfix) with ESMTP id 9A3275E289; Sun, 17 Jul 2005 13:26:01 +0200 (CEST) In-Reply-To: <42D67A29.9030100@bugest.net> References: <42D67A29.9030100@bugest.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <12e46a78a25fbbbafb26b1b4a5a38602@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Sun, 17 Jul 2005 13:16:35 +0200 To: Kosuke Ito X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, El 14/07/2005, a las 16:43, Kosuke Ito escribi=F3: > > Do we like to creat SWAMP already? > i fail to understand why this change would create swamp? could you=20 expand on this? > > Regarding the assignment size, when we held JP Open Policy > Meeting last week, there are many voices saying that > varying assignment size is too much impact on the current > commercial service not in its network operation but also > for the low-cost routing devices handling /48. > why would this have such impact on devices? do they have the /48=20 hardcoded? could you expand on this point? > According to them, they have already been in service, > so they consider that it is not practical to change the > assignment policy. I guess it is easier if all users get a /48 indeed, but how much effort=20= is required to determine the proper prefix for each costumer? is there=20= any additional operational cost that you could let us know? > Is it practical to change in other regions? > We had a discussion about IPv6 address management in the LACNIC VIII=20 meeting in Lima (30 of june 2005) and my reading of the comments of the=20= meeting is that they are pretty much in line with the considerations=20 expressed by Thomas in his drafts. Regards, marcelo > I believe that we can avoid any change in the policy > if we look back the goals and refrain from asking as > large allocation size and large assignment size as > possible just because they can. > > Nevertheless, if we keep the current pace of allocation, > one extrapolation study said that IPv6 might be allocated > 50% in 60 years in the worst(?) case. > Seems to me, lasting 120 years of IPv6 is long enough, > isn't it?? > > Kosuke > > > JORDI PALET MARTINEZ wrote: > >> Hi Thomas, >> I totally agree with your appreciations. >> May be one possibility to ensure that this is going to work also with=20= >> the >> RIRs is to hold this document until the RIRs policy changes align to=20= >> it, and >> work pro-actively with them in order to make that happening ASAP ? >> I will suggest a small change to this text (section 2): >> "... While that number may >> make sense for larger sites, it is hard to imagine a typical home >> user requiring so much space. Indeed, the default end site=20 >> assignment >> today is in practice the same for home users and larger=20 >> businesses." >> For something such as: >> "... While that number may >> make sense for larger sites, it is hard to imagine, at the time=20 >> being, a >> typical home user requiring so much space, but this can change and we=20= >> must >> be ready and open to that. Indeed, the default end site assignment=20 >> today is >> in practice the same for home users and large businesses. >> Moreover, the change in the recommended assignment (from /48 to /56)=20= >> should >> not become a barrier for any customer to get a /48 from the ISP,=20 >> whenever >> the ISP is required for that, with no need for further justifications=20= >> for >> that request." >> One open question is if this change will impact in the default=20 >> allocation of >> /32 to the LIRs. I mean, should they still keep considering that the >> customers will be able to request a /48 and consequently keep=20 >> allocating the >> big prefixes that we have seen until now ? If not, should the big=20 >> prefixes >> already allocated be claimed back ? Yes, I know is a RIR business,=20 >> but I >> think otherwise we clarify it ASAP, it can create a lot of unfairness=20= >> in the >> process with future allocations. >> Moreover, it will be a good suggestion for ISPs to block the=20 >> remaining /56 >> up to the /48 for each customer, in case he ask for it, in order to=20= >> avoid >> renumbering ? If that's the case, there is any meaning for this = change >> towards the conservation ?. >> Note that there is already some people proposing that the business=20 >> model for >> IPv6 is precisely charging for the addresses, which I believe is=20 >> totally >> broken and a wrong approach. The business will come because there are=20= >> new >> services and applications, for which the ISPs will be able to charge,=20= >> either >> because the service itself or the BW required by the service, or a >> combination of both. This will not happen if the addresses aren't=20 >> available >> for free (the applications will never come in that case, and we will=20= >> end-up >> with a NATv6 model). Also some ISPs in AP are already providing only=20= >> a /64 >> and charging for a different "service class" if the customer ask for=20= >> several >> subnets. >> Regards, >> Jordi >> (note: I've copied the globa-v6 list as suggested in previous emails=20= >> from >> Thomas) >>> De: Thomas Narten >>> Responder a: >>> Fecha: Thu, 14 Jul 2005 10:11:19 +0200 >>> Para: >>> CC: "ipv6@ietf.org" >>> Asunto: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >>> >>> Hi Jordi. >>> >>> >>>> I've read yesterday this document, and I'm basically ok with it,=20 >>>> but with >>>> two considerations that I think must be worked out it parallel=20 >>>> somehow: >>>> 1) HD-Ratio modification, as it seems to be an integral part of the >>>> discussion. >>> >>> IMO, changing the HD-ratio is a no-brainer, and I suspect that many >>> people feel the same way. It's an easy change to make and has = minimal >>> impact. Indeed, there is already an ARIN proposal to do this: >>> >>> http://www.arin.net/policy/proposals/2005_5.html >>> >>> So yes, I expect this will be done and will personally push to see >>> this happen. >>> >>> >>>> 2) I've the feeling that if we suggest the ISPs to move to a /56,=20= >>>> they will >>>> then charge the customers (SOHO, end-users) or create to them a lot=20= >>>> of >>>> troubles to get a bigger prefix when this is needed. >>> >>> We should be careful NOT to assume that just because something is=20 >>> done >>> one way in IPv4, it will be similar in IPv6. >>> >>> Indeed, I think one of the big cultural changes w.r.t. IPv6 is the >>> notion that end sites get subnets (emphasis on plural) where this is >>> clearly NOT the norm for IPv4 today. My sense is (from talking to=20 >>> folk >>> in the RIR community) is that they all believe this, and that ISPs >>> working with IPv6 also get this. So I think we've already changed = the >>> starting point here. >>> >>> Also, in IPv4, the existing practice is to give out a single >>> address. There are multiple reasons for this, some cultural (i.e., >>> status quo). But another point that I think people sometimes forget=20= >>> is >>> that the existing protocols and busines practices have been built >>> around giving out a single address (rather than a subnet) and such, >>> getting a subnet is, in fact, an exception to the norm. As we know, >>> exceptions can cost more, i.e., in terms of help desk support, etc. >>> >>> So even though ISPs in IPv4 do tend to charge more for "more than = one >>> address", the reasons for that are a bit subtle, and when they say=20= >>> its >>> because "more address just cost more", that is really just FUD. In = no >>> case can the case be made that it is because the extra addresses >>> actually "cost more", i.e., in terms of RIR policies. >>> >>> Again, my sense in the RIR regions is that folk want the RIR = policies >>> to be very clear that addresses should be available to end sites at >>> very low cost (i.e., essentially free), and that the cost of a /48 >>> should be the same as a /56 or /64. And with DHCPv6 prefix = delegation >>> (as the protocol/operational mechanism for achieving this) I think = we >>> are on track to see the right thing happen. >>> >>> To ensure that happens, the RIR policies will need to be sure that >>> when LIRs need more space from RIRs, the justification should be >>> based entirely on whether the existing space is sufficiently = utilized >>> (based on the HD-ratio) with the metric being completely neutral as=20= >>> to >>> whether end sites are getting /48s or /56s. >>> >>> >>>> My feeling is that today we believe that 8 bits for subnetting is >>>> enough, but I think will not be the case soon and this barrier will >>>> then be again a stopper for enabling innovation. >>> >>> I think there is a general feeling in the RIR community that folks >>> that ask for more than a /56 should generally get it more-or-less by >>> asking. I'd welcome help in how to word this. What we don't want is >>> folk automatically asking for a /48 "just because they can". In >>> practice, a /56 will really be enough for a large percentage of end >>> sites, for a long while. Hence, the current "justification" for = space >>> is probably best expressed in terms of size of a site in terms of >>> subnets. That is something objectively measurable and captures the >>> sense of whether additional space is really needed. >>> >>> >>>> I know this one is somehow not an IETF business, but we must be >>>> worried about that and may be collectively work for the appropriate >>>> solution in the appropriate fora. >>> >>> We simply need to pay attention to what is going on in the RIR >>> community, and followup as appropriate. The good news is that my own >>> sense (from going to ARIN meetings for 3 years or so, and attending >>> the last RIPE meeting) is that the community there largely shares = the >>> same goals as I'm hearing here. They do understand that IPv6 is >>> different than IPv4 and that we need to focus less on conservation >>> than IPv4. I think that most of the community is actually quite = happy >>> about this. >>> >>> >>>> The cost of managing addresses is not a recurrent cost. I mean, it=20= >>>> will be >>>> ok to charge for a reasonable setup fee if somebody ask for a /48=20= >>>> instead of >>>> a /56, but charging 12Euros (or even more) per month per address as=20= >>>> some >>>> telcos do in EU is a crime. >>> >>> No. I think there is no justification (in increased $$) for a /48 >>> vs. a /56. The RIR policies should be clear about that. That won't >>> prevent ISPs from (perhaps) doing this, but they will use weaker >>> arguments like "a /48 implies more traffic and therefore more $$".=20= >>> But >>> then again maybe not. In practice, with a /56, end sites can = generate >>> plenty of traffic and ISP charges may end up having to switch to >>> something based on actual traffice being carried. >>> >>> Thomas >>> >>> -------------------------------------------------------------------- >>> 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 >> Barcelona 2005 Global IPv6 Summit >> Information available at: >> http://www.ipv6-es.com >> This electronic message contains information which may be privileged=20= >> or confidential. The information is intended to be for the use of the=20= >> individual(s) named above. If you are not the intended recipient be=20= >> aware that any disclosure, copying, distribution or use of the=20 >> contents of this information, including attached files, is=20 >> prohibited. >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > --=20 > **********IPv6 Internet Wonderland!************ > Kosuke Ito, Master Planning and Steering Group > IPv6 Promotion Council of Japan > (Visiting Researcher, SFC Lab. KEIO University) > Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 > Cell:+81-90-4605-4581 > mailto: kosuke@v6pc.jp http://www.v6pc.jp/ > Lifetime e-mail: kosuke@stanfordalumni.org > > _______________________________________________ > global-v6 mailing list > global-v6@lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 18 03:07:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuPjD-0004m6-GK; Mon, 18 Jul 2005 03:07:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuPj8-0004ip-Qj for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 03:07:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15982 for ; Mon, 18 Jul 2005 03:07:45 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuQCV-00081t-DZ for ipv6@ietf.org; Mon, 18 Jul 2005 03:38:08 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6I77hoN027538; Mon, 18 Jul 2005 10:07:43 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 10:06:55 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 10:06:55 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.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 Jul 2005 10:06:54 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CE94C@esebe100.NOE.Nokia.com> Thread-Topic: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt Thread-Index: AcWH9HhMZpiT59+UQyi1bVMJx7eMKgBqA/yAAHKDHgA= To: , , X-OriginalArrivalTime: 18 Jul 2005 07:06:55.0585 (UTC) FILETIME=[48011510:01C58B67] X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > I said part of this on the ARIN PPML list but thought it should be = repeated > here.=20 >=20 > A /64 allocation never makes any sense. The claims about a PDA only = needing > one assume that it will never be dropped into a cradle of a vehicle = suddenly > enabling various subnets (freight environmental or inventory monitor, > dispatch service) to reach out or be reached with independent access > controls. A /64 puts the carrier in the position of telling the = customer > they can't build anything more than a single lan, where a /60 removes = that > limitation with effectively the same impact on space utilization. I tend to agree with Tony here. PDA's are getting higher bandwidth (thanks to WiFi and 3G connections) and are mobile, so that this = distinction is becoming blurred. Additionally, there seems to be a trend out of = sharing high-speed data connections, so a PDA in a cradle could provide = connectivity more many users. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 18 06:34:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuSxc-0007or-7u; Mon, 18 Jul 2005 06:34:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuSrP-00074u-Nb for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 06:28:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28914 for ; Mon, 18 Jul 2005 06:28:29 -0400 (EDT) Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DuTKn-0005ar-Pm for ipv6@ietf.org; Mon, 18 Jul 2005 06:58:55 -0400 Received: (qmail 63625 invoked by uid 1007); 18 Jul 2005 10:28:13 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=mc9osGfOjrdthlMzEugU9wR7AR5+PBvevXrtvrfe1VkRtKc2l9IqgG2hKg/PYBr+ ; Date: Mon, 18 Jul 2005 12:28:13 +0200 From: Gert Doering To: JORDI PALET MARTINEZ Message-ID: <20050718102813.GZ84850@Space.Net> References: <200507140811.j6E8BJgl014068@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Mon, 18 Jul 2005 06:34:53 -0400 Cc: "ipv6@ietf.org" , global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, On Thu, Jul 14, 2005 at 11:31:31AM +0200, JORDI PALET MARTINEZ wrote: > One open question is if this change will impact in the default allocation of > /32 to the LIRs. I mean, should they still keep considering that the > customers will be able to request a /48 and consequently keep allocating the > big prefixes that we have seen until now ? If not, should the big prefixes > already allocated be claimed back ? Yes, I know is a RIR business, but I > think otherwise we clarify it ASAP, it can create a lot of unfairness in the > process with future allocations. /32s are *not* "big prefixes". What are you aiming for? Reduce the ISP minimum allocation size - for what good? If all the IPv6 space is handed out as /32s, we have 4 billion routes - which is very bad. Anything aiming for even smaller blocks (longer prefix) is going the wrong way - brings some benefit to conservation but hurts routing. > Moreover, it will be a good suggestion for ISPs to block the remaining /56 > up to the /48 for each customer, in case he ask for it, in order to avoid > renumbering ? If that's the case, there is any meaning for this change > towards the conservation ?. This suggestion is not useful. If you reserve the rest of the /48, then you can hand out the /48 in the first place, and be done with it. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 18 06:46:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuT9D-0001xy-II; Mon, 18 Jul 2005 06:46:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuT9B-0001xt-73 for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 06:46:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29869 for ; Mon, 18 Jul 2005 06:46:50 -0400 (EDT) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuTcZ-0006gR-35 for ipv6@ietf.org; Mon, 18 Jul 2005 07:17:17 -0400 Received: from [10.10.10.100] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001152117.msg for ; Mon, 18 Jul 2005 12:47:56 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 18 Jul 2005 12:46:24 +0200 From: JORDI PALET MARTINEZ To: "ipv6@ietf.org" , Message-ID: In-Reply-To: <20050718102813.GZ84850@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es 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 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Processed: consulintel.es, Mon, 18 Jul 2005 12:47:57 +0200 X-MDAV-Processed: consulintel.es, Mon, 18 Jul 2005 12:47:59 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Gert, See below, in-line. Regards, Jordi > De: Gert Doering > Responder a: > Fecha: Mon, 18 Jul 2005 12:28:13 +0200 > Para: JORDI PALET MARTINEZ > CC: "ipv6@ietf.org" , > Asunto: Re: [GLOBAL-V6] Re: I-D > ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > Hi, > > On Thu, Jul 14, 2005 at 11:31:31AM +0200, JORDI PALET MARTINEZ wrote: >> One open question is if this change will impact in the default allocation of >> /32 to the LIRs. I mean, should they still keep considering that the >> customers will be able to request a /48 and consequently keep allocating the >> big prefixes that we have seen until now ? If not, should the big prefixes >> already allocated be claimed back ? Yes, I know is a RIR business, but I >> think otherwise we clarify it ASAP, it can create a lot of unfairness in the >> process with future allocations. > > /32s are *not* "big prefixes". No, I was not referring to /32, but to the big allocations, such as /1x or /2x, for example. > > What are you aiming for? > > Reduce the ISP minimum allocation size - for what good? What I'm trying to say is that if we change the policy, and those that now can get, for example a /24 and with the new policy will only get a /28, have the same right to still get the /24, unless those that got the /24 (now) get it reduced to /28. Just an example, hopefully is now more clear. Otherwise, we are behaving in a very unfair way. Note that I don't want that this happens, I'm just explaining my view point about how unfair the situation will be. > > If all the IPv6 space is handed out as /32s, we have 4 billion routes - which > is very bad. Anything aiming for even smaller blocks (longer prefix) is > going the wrong way - brings some benefit to conservation but hurts routing. Totally agree, I guess I was not clear, hopefully now is much better ! > >> Moreover, it will be a good suggestion for ISPs to block the remaining /56 >> up to the /48 for each customer, in case he ask for it, in order to avoid >> renumbering ? If that's the case, there is any meaning for this change >> towards the conservation ?. > > This suggestion is not useful. If you reserve the rest of the /48, then > you can hand out the /48 in the first place, and be done with it. That's was my point ;-) > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 71007 (66629) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > D- 80807 Muenchen Fax : +49-89-32356-234 > ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com 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 Mon Jul 18 09:24:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuVbH-000168-0f; Mon, 18 Jul 2005 09:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuVQ9-0007Ar-KN for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 09:12:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09196 for ; Mon, 18 Jul 2005 09:12:32 -0400 (EDT) Received: from fj34.ade2.point.ne.jp ([61.117.244.34] helo=nereid.bugest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuVtX-0007s6-34 for ipv6@ietf.org; Mon, 18 Jul 2005 09:42:58 -0400 Received: from bugest.net (nereid.bugest.net [172.16.0.5]) by nereid.bugest.net (Postfix) with ESMTP id 7B71E3A21B; Mon, 18 Jul 2005 22:12:19 +0900 (JST) Message-ID: <42DBAAB4.30205@bugest.net> Date: Mon, 18 Jul 2005 22:12:20 +0900 From: Kosuke Ito Organization: IPv6 Promotion Council of Japan / Canon Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: marcelo bagnulo braun References: <42D67A29.9030100@bugest.net> <12e46a78a25fbbbafb26b1b4a5a38602@it.uc3m.es> In-Reply-To: <12e46a78a25fbbbafb26b1b4a5a38602@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 18 Jul 2005 09:24:01 -0400 Cc: ipv6@ietf.org, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org marcelo bagnulo braun wrote: > Hi, >=20 > El 14/07/2005, a las 16:43, Kosuke Ito escribi=F3: >=20 >> >=20 >> Do we like to creat SWAMP already? >> >=20 > i fail to understand why this change would create swamp? could you=20 > expand on this? I just extend my imagination that we may be about stepping into the same mistake we made for IPv4, such as network management nightmare of managing sider space, longer prefix allocation, etc. which swell ISPs management cost. But maybe, the minimum initial allocation of /32 would not be changed, wouldn't it? Then, my SWAMP statement made before would not be the case. >> >> Regarding the assignment size, when we held JP Open Policy >> Meeting last week, there are many voices saying that >> varying assignment size is too much impact on the current >> commercial service not in its network operation but also >> for the low-cost routing devices handling /48. >> >=20 > why would this have such impact on devices? do they have the /48=20 > hardcoded? could you expand on this point? Many of home routers sold in Japan is designed and build to associate with an ISP's service operational scheme. Currently, a home router receiving /48 from the ISP block and assigned a /64 out of it automatically ( and manually done by the user if necessary). >> According to them, they have already been in service, >> so they consider that it is not practical to change the >> assignment policy. >=20 >=20 > I guess it is easier if all users get a /48 indeed, but how much effort= =20 > is required to determine the proper prefix for each costumer? is there=20 > any additional operational cost that you could let us know? If the assignment size gets various, more overhead functionality needs to be implemented into the home router to set the appropriate assignemnt size user by user, and/or ISP needs to decide its size user by user (since the size of assignment under /48 is determined by ISPs). Who pay this price? >=20 >> Is it practical to change in other regions? >> >=20 > We had a discussion about IPv6 address management in the LACNIC VIII=20 > meeting in Lima (30 of june 2005) and my reading of the comments of the= =20 > meeting is that they are pretty much in line with the considerations=20 > expressed by Thomas in his drafts. Thank you. How many acctual/commercial assignments have been made (or registered) in LACNIC area? Kosuke > Regards, marcelo >=20 >=20 >> I believe that we can avoid any change in the policy >> if we look back the goals and refrain from asking as >> large allocation size and large assignment size as >> possible just because they can. >> >> Nevertheless, if we keep the current pace of allocation, >> one extrapolation study said that IPv6 might be allocated >> 50% in 60 years in the worst(?) case. >> Seems to me, lasting 120 years of IPv6 is long enough, >> isn't it?? >> >> Kosuke >> >> >> JORDI PALET MARTINEZ wrote: >> >>> Hi Thomas, >>> I totally agree with your appreciations. >>> May be one possibility to ensure that this is going to work also with= =20 >>> the >>> RIRs is to hold this document until the RIRs policy changes align to=20 >>> it, and >>> work pro-actively with them in order to make that happening ASAP ? >>> I will suggest a small change to this text (section 2): >>> "... While that number may >>> make sense for larger sites, it is hard to imagine a typical home >>> user requiring so much space. Indeed, the default end site assignm= ent >>> today is in practice the same for home users and larger businesses= ." >>> For something such as: >>> "... While that number may >>> make sense for larger sites, it is hard to imagine, at the time being= , a >>> typical home user requiring so much space, but this can change and we= =20 >>> must >>> be ready and open to that. Indeed, the default end site assignment=20 >>> today is >>> in practice the same for home users and large businesses. >>> Moreover, the change in the recommended assignment (from /48 to /56)=20 >>> should >>> not become a barrier for any customer to get a /48 from the ISP,=20 >>> whenever >>> the ISP is required for that, with no need for further justifications= =20 >>> for >>> that request." >>> One open question is if this change will impact in the default=20 >>> allocation of >>> /32 to the LIRs. I mean, should they still keep considering that the >>> customers will be able to request a /48 and consequently keep=20 >>> allocating the >>> big prefixes that we have seen until now ? If not, should the big=20 >>> prefixes >>> already allocated be claimed back ? Yes, I know is a RIR business, bu= t I >>> think otherwise we clarify it ASAP, it can create a lot of unfairness= =20 >>> in the >>> process with future allocations. >>> Moreover, it will be a good suggestion for ISPs to block the=20 >>> remaining /56 >>> up to the /48 for each customer, in case he ask for it, in order to=20 >>> avoid >>> renumbering ? If that's the case, there is any meaning for this chang= e >>> towards the conservation ?. >>> Note that there is already some people proposing that the business=20 >>> model for >>> IPv6 is precisely charging for the addresses, which I believe is tota= lly >>> broken and a wrong approach. The business will come because there are= =20 >>> new >>> services and applications, for which the ISPs will be able to charge,= =20 >>> either >>> because the service itself or the BW required by the service, or a >>> combination of both. This will not happen if the addresses aren't=20 >>> available >>> for free (the applications will never come in that case, and we will=20 >>> end-up >>> with a NATv6 model). Also some ISPs in AP are already providing only=20 >>> a /64 >>> and charging for a different "service class" if the customer ask for=20 >>> several >>> subnets. >>> Regards, >>> Jordi >>> (note: I've copied the globa-v6 list as suggested in previous emails=20 >>> from >>> Thomas) >>> >>>> De: Thomas Narten >>>> Responder a: >>>> Fecha: Thu, 14 Jul 2005 10:11:19 +0200 >>>> Para: >>>> CC: "ipv6@ietf.org" >>>> Asunto: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >>>> >>>> Hi Jordi. >>>> >>>> >>>>> I've read yesterday this document, and I'm basically ok with it,=20 >>>>> but with >>>>> two considerations that I think must be worked out it parallel=20 >>>>> somehow: >>>>> 1) HD-Ratio modification, as it seems to be an integral part of the >>>>> discussion. >>>> >>>> >>>> IMO, changing the HD-ratio is a no-brainer, and I suspect that many >>>> people feel the same way. It's an easy change to make and has minima= l >>>> impact. Indeed, there is already an ARIN proposal to do this: >>>> >>>> http://www.arin.net/policy/proposals/2005_5.html >>>> >>>> So yes, I expect this will be done and will personally push to see >>>> this happen. >>>> >>>> >>>>> 2) I've the feeling that if we suggest the ISPs to move to a /56,=20 >>>>> they will >>>>> then charge the customers (SOHO, end-users) or create to them a lot= of >>>>> troubles to get a bigger prefix when this is needed. >>>> >>>> >>>> We should be careful NOT to assume that just because something is do= ne >>>> one way in IPv4, it will be similar in IPv6. >>>> >>>> Indeed, I think one of the big cultural changes w.r.t. IPv6 is the >>>> notion that end sites get subnets (emphasis on plural) where this is >>>> clearly NOT the norm for IPv4 today. My sense is (from talking to fo= lk >>>> in the RIR community) is that they all believe this, and that ISPs >>>> working with IPv6 also get this. So I think we've already changed th= e >>>> starting point here. >>>> >>>> Also, in IPv4, the existing practice is to give out a single >>>> address. There are multiple reasons for this, some cultural (i.e., >>>> status quo). But another point that I think people sometimes forget = is >>>> that the existing protocols and busines practices have been built >>>> around giving out a single address (rather than a subnet) and such, >>>> getting a subnet is, in fact, an exception to the norm. As we know, >>>> exceptions can cost more, i.e., in terms of help desk support, etc. >>>> >>>> So even though ISPs in IPv4 do tend to charge more for "more than on= e >>>> address", the reasons for that are a bit subtle, and when they say i= ts >>>> because "more address just cost more", that is really just FUD. In n= o >>>> case can the case be made that it is because the extra addresses >>>> actually "cost more", i.e., in terms of RIR policies. >>>> >>>> Again, my sense in the RIR regions is that folk want the RIR policie= s >>>> to be very clear that addresses should be available to end sites at >>>> very low cost (i.e., essentially free), and that the cost of a /48 >>>> should be the same as a /56 or /64. And with DHCPv6 prefix delegatio= n >>>> (as the protocol/operational mechanism for achieving this) I think w= e >>>> are on track to see the right thing happen. >>>> >>>> To ensure that happens, the RIR policies will need to be sure that >>>> when LIRs need more space from RIRs, the justification should be >>>> based entirely on whether the existing space is sufficiently utilize= d >>>> (based on the HD-ratio) with the metric being completely neutral as = to >>>> whether end sites are getting /48s or /56s. >>>> >>>> >>>>> My feeling is that today we believe that 8 bits for subnetting is >>>>> enough, but I think will not be the case soon and this barrier will >>>>> then be again a stopper for enabling innovation. >>>> >>>> >>>> I think there is a general feeling in the RIR community that folks >>>> that ask for more than a /56 should generally get it more-or-less by >>>> asking. I'd welcome help in how to word this. What we don't want is >>>> folk automatically asking for a /48 "just because they can". In >>>> practice, a /56 will really be enough for a large percentage of end >>>> sites, for a long while. Hence, the current "justification" for spac= e >>>> is probably best expressed in terms of size of a site in terms of >>>> subnets. That is something objectively measurable and captures the >>>> sense of whether additional space is really needed. >>>> >>>> >>>>> I know this one is somehow not an IETF business, but we must be >>>>> worried about that and may be collectively work for the appropriate >>>>> solution in the appropriate fora. >>>> >>>> >>>> We simply need to pay attention to what is going on in the RIR >>>> community, and followup as appropriate. The good news is that my own >>>> sense (from going to ARIN meetings for 3 years or so, and attending >>>> the last RIPE meeting) is that the community there largely shares th= e >>>> same goals as I'm hearing here. They do understand that IPv6 is >>>> different than IPv4 and that we need to focus less on conservation >>>> than IPv4. I think that most of the community is actually quite happ= y >>>> about this. >>>> >>>> >>>>> The cost of managing addresses is not a recurrent cost. I mean, it=20 >>>>> will be >>>>> ok to charge for a reasonable setup fee if somebody ask for a /48=20 >>>>> instead of >>>>> a /56, but charging 12Euros (or even more) per month per address as= =20 >>>>> some >>>>> telcos do in EU is a crime. >>>> >>>> >>>> No. I think there is no justification (in increased $$) for a /48 >>>> vs. a /56. The RIR policies should be clear about that. That won't >>>> prevent ISPs from (perhaps) doing this, but they will use weaker >>>> arguments like "a /48 implies more traffic and therefore more $$". B= ut >>>> then again maybe not. In practice, with a /56, end sites can generat= e >>>> plenty of traffic and ISP charges may end up having to switch to >>>> something based on actual traffice being carried. >>>> >>>> Thomas >>>> >>>> -------------------------------------------------------------------- >>>> 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 >>> Barcelona 2005 Global IPv6 Summit >>> Information available at: >>> http://www.ipv6-es.com >>> This electronic message contains information which may be privileged=20 >>> or confidential. The information is intended to be for the use of the= =20 >>> individual(s) named above. If you are not the intended recipient be=20 >>> aware that any disclosure, copying, distribution or use of the=20 >>> 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 >>> -------------------------------------------------------------------- >> >> >> >> --=20 >> **********IPv6 Internet Wonderland!************ >> Kosuke Ito, Master Planning and Steering Group >> IPv6 Promotion Council of Japan >> (Visiting Researcher, SFC Lab. KEIO University) >> Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 >> Cell:+81-90-4605-4581 >> mailto: kosuke@v6pc.jp http://www.v6pc.jp/ >> Lifetime e-mail: kosuke@stanfordalumni.org >> >> _______________________________________________ >> global-v6 mailing list >> global-v6@lists.apnic.net >> http://mailman.apnic.net/mailman/listinfo/global-v6 >> >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 --=20 **********IPv6 Internet Wonderland!************ Kosuke Ito, Master Planning and Steering Group IPv6 Promotion Council of Japan (Visiting Researcher, SFC Lab. KEIO University) Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 Cell:+81-90-4605-4581 mailto: kosuke@v6pc.jp http://www.v6pc.jp/ Lifetime e-mail: kosuke@stanfordalumni.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 Jul 18 09:36:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuVnC-0004aP-Mu; Mon, 18 Jul 2005 09:36:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuVn9-0004aK-KF for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 09:36:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10725 for ; Mon, 18 Jul 2005 09:36:17 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuWGX-0000wQ-J7 for ipv6@ietf.org; Mon, 18 Jul 2005 10:06:44 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DC8E45E49F; Mon, 18 Jul 2005 15:36:06 +0200 (CEST) Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp01.uc3m.es (Postfix) with ESMTP id 9DB7E5E473; Mon, 18 Jul 2005 15:36:06 +0200 (CEST) In-Reply-To: <42DBAAB4.30205@bugest.net> References: <42D67A29.9030100@bugest.net> <12e46a78a25fbbbafb26b1b4a5a38602@it.uc3m.es> <42DBAAB4.30205@bugest.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9fa1a200dfc86ec0749a3641f57e0dbb@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Mon, 18 Jul 2005 15:36:10 +0200 To: Kosuke Ito X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Kosuke, El 18/07/2005, a las 15:12, Kosuke Ito escribi=F3: > marcelo bagnulo braun wrote: > >> Hi, >> El 14/07/2005, a las 16:43, Kosuke Ito escribi=F3: >>> >>> Do we like to creat SWAMP already? >>> >> i fail to understand why this change would create swamp? could you =20= >> expand on this? > > I just extend my imagination that we may be about stepping > into the same mistake we made for IPv4, such as network > management nightmare of managing sider space, longer prefix > allocation, etc. which swell ISPs management cost. > But maybe, the minimum initial allocation of /32 would not be > changed, wouldn't it? > well, i guess that these are two different issues: - on one hand, the size of end-sites assigments, which seems to be one =20= of the main focus of the discussion here (to move it from /48 to /56) - on the other hand, whether this change, would imply a change in the =20= minimum allocation to lirs IMHO, i am much more concerned with the first point than with the =20 second point. I mean, i can live with the /32, but i am worried about =20= the /48 (Besides, probably changing the /48 would also impact in the size of =20 bigger allocations (i.e. prefix shorter than 32 bots) since now each =20 site won't account for a /48) > Then, my SWAMP statement made before would not be the case. > >>> >>> Regarding the assignment size, when we held JP Open Policy >>> Meeting last week, there are many voices saying that >>> varying assignment size is too much impact on the current >>> commercial service not in its network operation but also >>> for the low-cost routing devices handling /48. >>> >> why would this have such impact on devices? do they have the /48 =20 >> hardcoded? could you expand on this point? > > Many of home routers sold in Japan is designed and build > to associate with an ISP's service operational scheme. > Currently, a home router receiving /48 from the ISP block > and assigned a /64 out of it automatically How does the router obtains the /48? is this automatic? does it uses =20 DHCP prefix option? > ( and manually > done by the user if necessary). > >>> According to them, they have already been in service, >>> so they consider that it is not practical to change the >>> assignment policy. >> I guess it is easier if all users get a /48 indeed, but how much =20 >> effort is required to determine the proper prefix for each costumer? =20= >> is there any additional operational cost that you could let us know? > > If the assignment size gets various, more overhead functionality > needs to be implemented into the home router to set the appropriate > assignemnt size user by user, and/or ISP needs to decide its size > user by user (since the size of assignment under /48 is determined > by ISPs). AFAIU, so far the proposal is to have two prefix lengths /48 for big =20 end sites and /56 for smaller sites. I am not sure how much more =20 complexity this would add... I mean, automatic prefix delegation using dhcp prefix option would =20 support this transparently. > Who pay this price? > obviously this an increased cost (there ain't no such thing as a free =20= lunch) But quite a few bits are not wasted so, i would need very good =20= reasons or very high costs (whatever you want to see it) not to support =20= this proposal. I so far, i am far from convinced that the costs =20 involved in the support of this policy are high, but i am open to be =20 convinced otherwise >>> Is it practical to change in other regions? >>> >> We had a discussion about IPv6 address management in the LACNIC VIII =20= >> meeting in Lima (30 of june 2005) and my reading of the comments of =20= >> the meeting is that they are pretty much in line with the =20 >> considerations expressed by Thomas in his drafts. > > Thank you. > How many acctual/commercial assignments have been made (or > registered) in LACNIC area? i will forward this question to lacnic people regards, marcelo > > Kosuke > >> Regards, marcelo >>> I believe that we can avoid any change in the policy >>> if we look back the goals and refrain from asking as >>> large allocation size and large assignment size as >>> possible just because they can. >>> >>> Nevertheless, if we keep the current pace of allocation, >>> one extrapolation study said that IPv6 might be allocated >>> 50% in 60 years in the worst(?) case. >>> Seems to me, lasting 120 years of IPv6 is long enough, >>> isn't it?? >>> >>> Kosuke >>> >>> >>> JORDI PALET MARTINEZ wrote: >>> >>>> Hi Thomas, >>>> I totally agree with your appreciations. >>>> May be one possibility to ensure that this is going to work also =20= >>>> with the >>>> RIRs is to hold this document until the RIRs policy changes align =20= >>>> to it, and >>>> work pro-actively with them in order to make that happening ASAP ? >>>> I will suggest a small change to this text (section 2): >>>> "... While that number may >>>> make sense for larger sites, it is hard to imagine a typical = home >>>> user requiring so much space. Indeed, the default end site =20 >>>> assignment >>>> today is in practice the same for home users and larger =20 >>>> businesses." >>>> For something such as: >>>> "... While that number may >>>> make sense for larger sites, it is hard to imagine, at the time =20 >>>> being, a >>>> typical home user requiring so much space, but this can change and =20= >>>> we must >>>> be ready and open to that. Indeed, the default end site assignment =20= >>>> today is >>>> in practice the same for home users and large businesses. >>>> Moreover, the change in the recommended assignment (from /48 to =20 >>>> /56) should >>>> not become a barrier for any customer to get a /48 from the ISP, =20= >>>> whenever >>>> the ISP is required for that, with no need for further =20 >>>> justifications for >>>> that request." >>>> One open question is if this change will impact in the default =20 >>>> allocation of >>>> /32 to the LIRs. I mean, should they still keep considering that = the >>>> customers will be able to request a /48 and consequently keep =20 >>>> allocating the >>>> big prefixes that we have seen until now ? If not, should the big =20= >>>> prefixes >>>> already allocated be claimed back ? Yes, I know is a RIR business, =20= >>>> but I >>>> think otherwise we clarify it ASAP, it can create a lot of =20 >>>> unfairness in the >>>> process with future allocations. >>>> Moreover, it will be a good suggestion for ISPs to block the =20 >>>> remaining /56 >>>> up to the /48 for each customer, in case he ask for it, in order to = =20 >>>> avoid >>>> renumbering ? If that's the case, there is any meaning for this =20 >>>> change >>>> towards the conservation ?. >>>> Note that there is already some people proposing that the business =20= >>>> model for >>>> IPv6 is precisely charging for the addresses, which I believe is =20= >>>> totally >>>> broken and a wrong approach. The business will come because there =20= >>>> are new >>>> services and applications, for which the ISPs will be able to =20 >>>> charge, either >>>> because the service itself or the BW required by the service, or a >>>> combination of both. This will not happen if the addresses aren't =20= >>>> available >>>> for free (the applications will never come in that case, and we =20 >>>> will end-up >>>> with a NATv6 model). Also some ISPs in AP are already providing =20 >>>> only a /64 >>>> and charging for a different "service class" if the customer ask =20= >>>> for several >>>> subnets. >>>> Regards, >>>> Jordi >>>> (note: I've copied the globa-v6 list as suggested in previous =20 >>>> emails from >>>> Thomas) >>>> >>>>> De: Thomas Narten >>>>> Responder a: >>>>> Fecha: Thu, 14 Jul 2005 10:11:19 +0200 >>>>> Para: >>>>> CC: "ipv6@ietf.org" >>>>> Asunto: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >>>>> >>>>> Hi Jordi. >>>>> >>>>> >>>>>> I've read yesterday this document, and I'm basically ok with it, =20= >>>>>> but with >>>>>> two considerations that I think must be worked out it parallel =20= >>>>>> somehow: >>>>>> 1) HD-Ratio modification, as it seems to be an integral part of =20= >>>>>> the >>>>>> discussion. >>>>> >>>>> >>>>> IMO, changing the HD-ratio is a no-brainer, and I suspect that = many >>>>> people feel the same way. It's an easy change to make and has =20 >>>>> minimal >>>>> impact. Indeed, there is already an ARIN proposal to do this: >>>>> >>>>> http://www.arin.net/policy/proposals/2005_5.html >>>>> >>>>> So yes, I expect this will be done and will personally push to see >>>>> this happen. >>>>> >>>>> >>>>>> 2) I've the feeling that if we suggest the ISPs to move to a /56, = =20 >>>>>> they will >>>>>> then charge the customers (SOHO, end-users) or create to them a =20= >>>>>> lot of >>>>>> troubles to get a bigger prefix when this is needed. >>>>> >>>>> >>>>> We should be careful NOT to assume that just because something is =20= >>>>> done >>>>> one way in IPv4, it will be similar in IPv6. >>>>> >>>>> Indeed, I think one of the big cultural changes w.r.t. IPv6 is the >>>>> notion that end sites get subnets (emphasis on plural) where this =20= >>>>> is >>>>> clearly NOT the norm for IPv4 today. My sense is (from talking to =20= >>>>> folk >>>>> in the RIR community) is that they all believe this, and that ISPs >>>>> working with IPv6 also get this. So I think we've already changed =20= >>>>> the >>>>> starting point here. >>>>> >>>>> Also, in IPv4, the existing practice is to give out a single >>>>> address. There are multiple reasons for this, some cultural (i.e., >>>>> status quo). But another point that I think people sometimes =20 >>>>> forget is >>>>> that the existing protocols and busines practices have been built >>>>> around giving out a single address (rather than a subnet) and = such, >>>>> getting a subnet is, in fact, an exception to the norm. As we = know, >>>>> exceptions can cost more, i.e., in terms of help desk support, = etc. >>>>> >>>>> So even though ISPs in IPv4 do tend to charge more for "more than =20= >>>>> one >>>>> address", the reasons for that are a bit subtle, and when they say = =20 >>>>> its >>>>> because "more address just cost more", that is really just FUD. In = =20 >>>>> no >>>>> case can the case be made that it is because the extra addresses >>>>> actually "cost more", i.e., in terms of RIR policies. >>>>> >>>>> Again, my sense in the RIR regions is that folk want the RIR =20 >>>>> policies >>>>> to be very clear that addresses should be available to end sites = at >>>>> very low cost (i.e., essentially free), and that the cost of a /48 >>>>> should be the same as a /56 or /64. And with DHCPv6 prefix =20 >>>>> delegation >>>>> (as the protocol/operational mechanism for achieving this) I think = =20 >>>>> we >>>>> are on track to see the right thing happen. >>>>> >>>>> To ensure that happens, the RIR policies will need to be sure that >>>>> when LIRs need more space from RIRs, the justification should be >>>>> based entirely on whether the existing space is sufficiently =20 >>>>> utilized >>>>> (based on the HD-ratio) with the metric being completely neutral =20= >>>>> as to >>>>> whether end sites are getting /48s or /56s. >>>>> >>>>> >>>>>> My feeling is that today we believe that 8 bits for subnetting is >>>>>> enough, but I think will not be the case soon and this barrier =20= >>>>>> will >>>>>> then be again a stopper for enabling innovation. >>>>> >>>>> >>>>> I think there is a general feeling in the RIR community that folks >>>>> that ask for more than a /56 should generally get it more-or-less =20= >>>>> by >>>>> asking. I'd welcome help in how to word this. What we don't want = is >>>>> folk automatically asking for a /48 "just because they can". In >>>>> practice, a /56 will really be enough for a large percentage of = end >>>>> sites, for a long while. Hence, the current "justification" for =20= >>>>> space >>>>> is probably best expressed in terms of size of a site in terms of >>>>> subnets. That is something objectively measurable and captures the >>>>> sense of whether additional space is really needed. >>>>> >>>>> >>>>>> I know this one is somehow not an IETF business, but we must be >>>>>> worried about that and may be collectively work for the =20 >>>>>> appropriate >>>>>> solution in the appropriate fora. >>>>> >>>>> >>>>> We simply need to pay attention to what is going on in the RIR >>>>> community, and followup as appropriate. The good news is that my =20= >>>>> own >>>>> sense (from going to ARIN meetings for 3 years or so, and = attending >>>>> the last RIPE meeting) is that the community there largely shares =20= >>>>> the >>>>> same goals as I'm hearing here. They do understand that IPv6 is >>>>> different than IPv4 and that we need to focus less on conservation >>>>> than IPv4. I think that most of the community is actually quite =20= >>>>> happy >>>>> about this. >>>>> >>>>> >>>>>> The cost of managing addresses is not a recurrent cost. I mean, =20= >>>>>> it will be >>>>>> ok to charge for a reasonable setup fee if somebody ask for a /48 = =20 >>>>>> instead of >>>>>> a /56, but charging 12Euros (or even more) per month per address =20= >>>>>> as some >>>>>> telcos do in EU is a crime. >>>>> >>>>> >>>>> No. I think there is no justification (in increased $$) for a /48 >>>>> vs. a /56. The RIR policies should be clear about that. That won't >>>>> prevent ISPs from (perhaps) doing this, but they will use weaker >>>>> arguments like "a /48 implies more traffic and therefore more $$". = =20 >>>>> But >>>>> then again maybe not. In practice, with a /56, end sites can =20 >>>>> generate >>>>> plenty of traffic and ISP charges may end up having to switch to >>>>> something based on actual traffice being carried. >>>>> >>>>> Thomas >>>>> >>>>> = -------------------------------------------------------------------=20 >>>>> - >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: =20 >>>>> https://www1.ietf.org/mailman/listinfo/ipv6 >>>>> = -------------------------------------------------------------------=20 >>>>> - >>>> >>>> ************************************ >>>> The IPv6 Portal: http://www.ipv6tf.org >>>> Barcelona 2005 Global IPv6 Summit >>>> Information available at: >>>> http://www.ipv6-es.com >>>> This electronic message contains information which may be =20 >>>> privileged or confidential. The information is intended to be for =20= >>>> the use of the individual(s) named above. If you are not the =20 >>>> intended recipient be aware that any disclosure, copying, =20 >>>> distribution or use of the contents of this information, including =20= >>>> attached files, is prohibited. >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: = https://www1.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>> >>> >>> >>> --=20 >>> **********IPv6 Internet Wonderland!************ >>> Kosuke Ito, Master Planning and Steering Group >>> IPv6 Promotion Council of Japan >>> (Visiting Researcher, SFC Lab. KEIO University) >>> Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 >>> Cell:+81-90-4605-4581 >>> mailto: kosuke@v6pc.jp http://www.v6pc.jp/ >>> Lifetime e-mail: kosuke@stanfordalumni.org >>> >>> _______________________________________________ >>> global-v6 mailing list >>> global-v6@lists.apnic.net >>> http://mailman.apnic.net/mailman/listinfo/global-v6 >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > --=20 > **********IPv6 Internet Wonderland!************ > Kosuke Ito, Master Planning and Steering Group > IPv6 Promotion Council of Japan > (Visiting Researcher, SFC Lab. KEIO University) > Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 > Cell:+81-90-4605-4581 > mailto: kosuke@v6pc.jp http://www.v6pc.jp/ > Lifetime e-mail: kosuke@stanfordalumni.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 Jul 18 09:37:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuVoe-0004gi-Ed; Mon, 18 Jul 2005 09:37:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuVoc-0004gd-GU for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 09:37:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10810 for ; Mon, 18 Jul 2005 09:37:49 -0400 (EDT) Received: from 213-136-24-43.adsl.bit.nl ([213.136.24.43] helo=purgatory.unfix.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuWI0-0000yW-J2 for ipv6@ietf.org; Mon, 18 Jul 2005 10:08:15 -0400 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 1759C7F80; Mon, 18 Jul 2005 15:37:24 +0200 (CEST) From: Jeroen Massar To: Kosuke Ito In-Reply-To: <42DBAAB4.30205@bugest.net> References: <42D67A29.9030100@bugest.net> <12e46a78a25fbbbafb26b1b4a5a38602@it.uc3m.es> <42DBAAB4.30205@bugest.net> Organization: Unfix Date: Mon, 18 Jul 2005 15:37:22 +0200 Message-Id: <1121693842.26319.11.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipv6@ietf.org, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Content-Type: multipart/mixed; boundary="===============0149958482==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0149958482== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xQcj+ZKvLtmozj96mdc9" --=-xQcj+ZKvLtmozj96mdc9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-07-18 at 22:12 +0900, Kosuke Ito wrote: > Thank you. > How many acctual/commercial assignments have been made (or > registered) in LACNIC area? See http://www.sixxs.net/tools/grh/dfp/lacnic/ Also for the other regions of course. Greets, Jeroen --=-xQcj+ZKvLtmozj96mdc9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBC27CSKaooUjM+fCMRAofoAJ9G2jqCMOwt3ONgqt7OFgakMhIllwCgn7UD 63d7lFSW2Djj5Qbx6wO6BiA= =fVbn -----END PGP SIGNATURE----- --=-xQcj+ZKvLtmozj96mdc9-- --===============0149958482== 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 -------------------------------------------------------------------- --===============0149958482==-- From ipv6-bounces@ietf.org Mon Jul 18 11:08:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXEo-0003NG-EM; Mon, 18 Jul 2005 11:08:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXEl-0003N8-9H for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 11:08:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19502 for ; Mon, 18 Jul 2005 11:08:52 -0400 (EDT) Received: from mail.syce.net ([192.16.178.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuXiB-0007cW-5m for ipv6@ietf.org; Mon, 18 Jul 2005 11:39:20 -0400 Received: from localhost (mail.syce.net [IPv6:2001:218:4fd::25]) by mail.syce.net (8.12.11/8.12.11) with ESMTP/inet6 id j6IF8Ltu005690; Tue, 19 Jul 2005 00:08:22 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Tue, 19 Jul 2005 00:08:23 +0900 (JST) Message-Id: <20050719.000823.52160553.fujisaki@syce.net> To: marcelo@it.uc3m.es From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) In-Reply-To: <9fa1a200dfc86ec0749a3641f57e0dbb@it.uc3m.es> References: <12e46a78a25fbbbafb26b1b4a5a38602@it.uc3m.es> <42DBAAB4.30205@bugest.net> <9fa1a200dfc86ec0749a3641f57e0dbb@it.uc3m.es> X-Mailer: Mew version 4.2 on XEmacs 21.4.15 (Security Through Obscurity) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: kosuke@bugest.net, ipv6@ietf.org, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Marcelo, | > Many of home routers sold in Japan is designed and build | > to associate with an ISP's service operational scheme. | > Currently, a home router receiving /48 from the ISP block | > and assigned a /64 out of it automatically | | How does the router obtains the /48? is this automatic? does it uses | DHCP prefix option? >From the address assignment view point, many ISPs in Japan use the DHCPv6 prefix option for residential users. So, TECHNICALLY, changing the assignment size may not be so hard for ISPs. However there may be some cases that ISPs have to check the DHCPv6 client devices' behavior, the independency of the /48 prefix size (/64 prefix selection, filtering function, and so on). | > If the assignment size gets various, more overhead functionality | > needs to be implemented into the home router to set the appropriate | > assignemnt size user by user, and/or ISP needs to decide its size | > user by user (since the size of assignment under /48 is determined | > by ISPs). | | AFAIU, so far the proposal is to have two prefix lengths /48 for big | end sites and /56 for smaller sites. I am not sure how much more | complexity this would add... | I mean, automatic prefix delegation using dhcp prefix option would | support this transparently. This may not be the IETF issue, but from the ISPs' service view point, changing the prefix size has a impact to existing service spec (of course, the spec includes the price of the service. Should ISPs provide existing /48 service and following /56 service as same price? Don't customers complain this?). And mixing the different size prefix may increase the cost of the address management (but this may not be a big problem as you said). -- Tomohiro Fujisaki -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 18 11:36:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXfl-0002dr-St; Mon, 18 Jul 2005 11:36:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXOz-00077O-MZ for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 11:19:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20417 for ; Mon, 18 Jul 2005 11:19:27 -0400 (EDT) Received: from fj34.ade2.point.ne.jp ([61.117.244.34] helo=nereid.bugest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuXsP-0008Np-OE for ipv6@ietf.org; Mon, 18 Jul 2005 11:49:55 -0400 Received: from bugest.net (nereid.bugest.net [172.16.0.5]) by nereid.bugest.net (Postfix) with ESMTP id D40123A218; Tue, 19 Jul 2005 00:19:23 +0900 (JST) Message-ID: <42DBC87C.5070103@bugest.net> Date: Tue, 19 Jul 2005 00:19:24 +0900 From: Kosuke Ito Organization: IPv6 Promotion Council of Japan / Canon Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Thomas Narten References: <200507161220.j6GCKFXD004875@cichlid.raleigh.ibm.com> In-Reply-To: <200507161220.j6GCKFXD004875@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 18 Jul 2005 11:36:48 -0400 Cc: "ipv6@ietf.org" , global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Thomas, Thomas Narten wrote: > Ito-san, > > You raise some good questions. Thank you :-) > >>I have been observing the current discussion on "reviewing >>the current policies and address allocation practices". >>Then, I felt that we should resort what a real issue is. >>Why do we need to change HD-Ratio? > > > To ensure that we really have plenty of IPv6 addresses to last us 100+ > years. Consider IPv4. Have we already run out? Some say effectively > yes, because now that we see that we will run out, addressing policy > has changed (to increase conservation) and it has become harder to get > them. Hence, we've been forced to change our behavior in response to a > decrease in the supply. I think we'd all agree that it is harder to > get IPv4 address space today than we ever want it to be for IPv6. > > If we actually end up using up a significant fraction of the IPv6 > address space in the next 50 years (even if there is then still plenty > left), we may find ourselves forced to change our consumption behavior > in anticipation of possibly running out. In order for there really to > be "plenty of addresses", we really want there to never be any serious > concern that we will run out. I guess, we need to levelize this degree of "concern", first. I understand that some (I don't know there are "Many" or not) starts worrying about it. > draft-narten-iana-rir-ipv6-considerations-00.txt tries to lay out the > rational for changing the policies to be more conservative. See also > > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf > > >>Why do we need to change an assignment size? > > > So that we don't ever finding ourselves in the postion of saying > "things sure would be better now had we only been a bit more > conservative from the start". It's easy to make policies more liberal > later (if necessary/desireable). It will be much more difficult to go > from a more liberal policy to an more conservative one later (look at > the IPv4 situation today). But we all agreed that "the goal of conservation is the least priority" but also all ISPs needs to keep it in their mind when they determined the user assignment size, don't we? We agree to go more liberal when we set the current policy. But I still believe that starting of allocating /2x size to requesting ISPs who has nothing but only because they have IPv4 customer is, I think, too far liberal. Is this the sound model that ISP never come back to RIR for sub-allocation? Is this not against the basics of address allocation that address provides when it is needed? >>If we change it/them, what do we have in return? > > > Increased confidence that there will be plenty of IPv6 addresses for > at least a hundred years. What safety factor do we need? how do all of us think? One study I raised said that it might be allcated upto 50% in 60 years. Does this make us confident in lasting IPv6 for 100 years? > >>Just reducing the pace of address consumption? > > > Yes, but I would phrase it differently. I'd argue it's more the case > to say "reduce the pace of address wastage". I don't think anyone > wants to prevent people from getting address space that they will > actually use. But as it stands now, we are handing out a lot of > address space that even ISPs who are getting that much are suggesting > is way more than they really need. I agree. But what level means wastage and what level means a room of reducing operational overhead for less operational cost for both sides of RIR/NIR and ISP/User. We need to discuss these points before getting into details of how. /48? or /56? or both? or various in between?... it might be just one of technical ways to solve the above questions. >>Do we like to creat SWAMP already? > > > The swamp is more about long prefixes that don't aggregate, leading to > many prefixes in the routing table. Changing the amount of space we > allocate to end sites doesn't change this. I just imagine that we might raise up the "initial" minimum allocation size issue if we get this discussion far more. But changing "initial" minimum allocation size has larger impact which many of us like to avoid, I beieve. > >>Let me looking back the original intention of implementing >>HD-Ratio. HD-Ratio was introduced to give ISPs an eligibility >>to request subsequent allocation automatically in order >>to achieve one of the goals raised in the policy, such as >>"reducing overhead". > > >>But in some point, RIRs start applying HD-Ratio to decide >>the "Initial" allocation size based on ISP's existing _IPv4_ >>customer size, and RIRs and community change the policy >>itself to fit its practice. After that, initial allocation >>size gets larger like /21 or /20 than ever before. I believe >>that there is a twist here. I do not deny the current >>practice done by RIRs, if RIRs believe that this practice >>is totally in-line of the global address management to keep >>in good order. >>But reviewing this practice could be less impact than >>considering to change the policy so as to achieve the >>slowing down the pace of allocation (if it is the goal >>of this discussion). > > > An interesting point. The large allocations we are seeing now do stem > from ISPs using their existing IPv4 infrastructure and applying the HD > ratio to that. I think that is consistent though with the original > policy. I.e., it said: > > 4.4. Consideration of IPv4 Infrastructure > > Where an existing IPv4 service provider requests IPv6 space > for eventual transition of existing services to IPv6, the > number of present IPv4 customers may be used to justify a > larger request than would be justified if based solely on the > IPv6 infrastructure. Which line says the allocation size is decided automatically based on the HD-Ratio table by applying the IPv4 customer size? It might be OK to decide its reserving space for the sake of globally scalable address management by RIRs internally. But I have a question in giving it all at once to the requester. > >>Regarding the assignment size, when we held JP Open Policy >>Meeting last week, there are many voices saying that >>varying assignment size is too much impact on the current >>commercial service not in its network operation but also >>for the low-cost routing devices handling /48. > > > Can someone explain why this is? What is the issue? > > >>According to them, they have already been in service, >>so they consider that it is not practical to change the >>assignment policy. But at the same time, ISPs need to make >>their best effort to achieve the goal of "conservation" still >>existing in the policy even it is not the first priority. >>Is it practical to change in other regions? > > > Personally, I think we probably don't need to do anything about the > existing allocations. So this would be for future allocations. (Then > again, if DHCP and prefix delegation is being used, how hard would > this be to change for existing home users?) > > Are there implementations or deployment scenarios that _assume_ that > they will get a /48? If so, in what ways are they using the 16 subnet > bits? I guess, in the real service, there is no reason for 16 bit subnet necessary, but just IETF(RFC) said. But if the larger space of freedom they have, the more of creativity of services/usages is increased. This is just my personal feeling. > >>I believe that we can avoid any change in the policy >>if we look back the goals and refrain from asking as >>large allocation size and large assignment size as >>possible just because they can. > > > To stop the large allocations, changing the HD ratio metric will save > only about 3 bits. That is, it will give save us about an order of > magnitude more space. But changing the /48 default to /56 produces two > orders of magnitude more in savings. Cutting the projected consumption > by three orders of magnitude is a huge amount of savings. One order is > quite a bit less. Only about 3 or 4 bits but it increases the factor of 8 or 16, which seems me a great deal. Maybe some of us do not think so, though. > >>Nevertheless, if we keep the current pace of allocation, one >>extrapolation study said that IPv6 might be allocated 50% in 60 >>years in the worst(?) case. Seems to me, lasting 120 years of IPv6 >>is long enough, isn't it?? > > > The main issue is that there is inherent uncertainty in > projections. We really don't know how many devices will be connected > to the network in 50 years. Our projections are at best estimates and > may be closer to guesses. Given that the most important problem IPv6 > is supposed to solve is the shortage of addresses, we really don't > want to get this part wrong. I truely share this point with you. I would like to see how discussion goes more. Good night :-) Kosuke > Thomas > _______________________________________________ > global-v6 mailing list > global-v6@lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 > -- **********IPv6 Internet Wonderland!************ Kosuke Ito, Master Planning and Steering Group IPv6 Promotion Council of Japan (Visiting Researcher, SFC Lab. KEIO University) Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 Cell:+81-90-4605-4581 mailto: kosuke@v6pc.jp http://www.v6pc.jp/ Lifetime e-mail: kosuke@stanfordalumni.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 Jul 18 11:50:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXt9-0006m2-Qr; Mon, 18 Jul 2005 11:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXt3-0006kB-KE; Mon, 18 Jul 2005 11:50:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23054; Mon, 18 Jul 2005 11:50:31 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuYMW-0002KD-1Z; Mon, 18 Jul 2005 12:21:00 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DuXt3-00019m-3q; Mon, 18 Jul 2005 11:50:33 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 18 Jul 2005 11:50:33 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Last Call: 'Privacy Extensions for Stateless Address Autoconfiguration in IPv6' to Draft Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'Privacy Extensions for Stateless Address Autoconfiguration in IPv6 ' as a Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-01. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-04.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 18 13:53:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuZns-0004iP-Eq; Mon, 18 Jul 2005 13:53:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuZnp-0004iK-NO for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 13:53:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01381 for ; Mon, 18 Jul 2005 13:53:16 -0400 (EDT) Message-Id: <200507181753.NAA01381@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuaHH-0001ks-8D for ipv6@ietf.org; Mon, 18 Jul 2005 14:23:45 -0400 Received: from eaglet (127.0.0.1:1654) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 18 Jul 2005 10:52:53 -0700 From: "Tony Hain" To: , , Date: Mon, 18 Jul 2005 10:50:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWKRsD7CxqVPicRSk+3t5ZataIzgwBeVwmg X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Content-Transfer-Encoding: 7bit Cc: Subject: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The operator never should know if the device has a backside interface, so the argument about /128 being valid is also wrong (/128's are the fastest track to an IPv6 NAT that there is). From the perspective of the operator they are selling access via a link, what the consumer does behind the device connected to the link (other than resell it) is not their business. They should be set up to allocate a prefix shorter than /64 in all cases. Tony > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > JORDI PALET MARTINEZ > Sent: Saturday, July 16, 2005 1:39 PM > To: global-v6@lists.apnic.net; ipv6@ietf.org > Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > I tend to agree with this. > > I see situations for assigning a /128 when a unique device is connected, > which is not going to route anything else, but once it has other > interfaces > (which is the most common case and will become more and more often) ... > > Regards, > Jordi > > > > > > De: Tony Hain > > Responder a: > > Fecha: Fri, 15 Jul 2005 17:40:24 -0700 > > Para: 'Thomas Narten' , > > Asunto: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > > > I said part of this on the ARIN PPML list but thought it should be > repeated > > here. > > > > A /64 allocation never makes any sense. The claims about a PDA only > needing > > one assume that it will never be dropped into a cradle of a vehicle > suddenly > > enabling various subnets (freight environmental or inventory monitor, > > dispatch service) to reach out or be reached with independent access > > controls. A /64 puts the carrier in the position of telling the customer > > they can't build anything more than a single lan, where a /60 removes > that > > limitation with effectively the same impact on space utilization. > > > > We bumped into another version of this when thinking through some of the > > issues with cable. The MSO's appear to be focusing around a prefix being > the > > unit of allocation to a customer. All well and good until we get the 'a > /64 > > is more than enough space' discussion. The issue crystallized when the > > discussion included a separate subnet for cable devices in the home to > > communicate locally. Since the MSO has bought into the concept of a > prefix > > maps to a customer, having independent /64's breaks the allocation and > > management model. The conservation mindset clashes with the simplified > > management mindset and documents with wording like this are not helping. > > > > This draft really needs to remove the discussion about a /64 being > > appropriate for anything from an allocation perspective. There is no > serious > > technical need for the draft to begin with, but if it exists it should > point > > out that a /60 is the longest prefix that allows customers to build > networks > > with multiple links (specifically technologies that don't bridge) and > maps > > cleanly onto the reverse delegation name tree. > > > > Tony > > > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > >> Thomas Narten > >> Sent: Wednesday, July 13, 2005 2:44 PM > >> To: ipv6@ietf.org > >> Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > >> > >> Here's an ID for consideration by the IPv6 WG. > >> > >> Background: > >> > >> Discussion on the more general topic took place at the April ARIN and > >> May RIPE meetings. A good summary of those presentations can be found > >> at: > >> > >> http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary- > >> wed-ipv6-roundtable-report.pdf > >> > >> A more general discussion of the overall topic of IPv6 address > >> allocation considerations (the /48 boundary topic is just one piece of > >> a larger puzzle) can be found at: > >> > >> http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6- > >> considerations-00.txt > >> > >> Thomas > >> > >> ------- Forwarded Message > >> > >> From: Internet-Drafts@ietf.org > >> To: i-d-announce@ietf.org > >> Date: Tue, 12 Jul 2005 15:50:03 -0400 > >> Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > >> Reply-To: internet-drafts@ietf.org > >> > >> --NextPart > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> Title : IPv6 Address Allocation to End Sites > >> Author(s) : T. Narten, et al. > >> Filename : draft-narten-ipv6-3177bis-48boundary-00.txt > >> Pages : 8 > >> Date : 2005-7-12 > >> > >> This document revisits the IAB/IESG recommendations on the > assignment > >> of IPv6 address space to end sites. Specifically, it indicates that > >> changing the default end-site assignment for typical home and SOHO > >> sites from /48 to /56 is consistent with the goals of IPv6 and RFC > >> 3177. Although it is for the RIR community to make adjustments to > the > >> IPv6 address space allocation and end site assignment policies, the > >> IETF community would be comfortable with RIRs changing the default > >> assignment size to /56 for smaller end sites. This document > obsoletes > >> RFC 3177 and reclassifies it as historic. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis- > 48boundary- > >> 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-narten-ipv6-3177bis-48boundary-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-narten-ipv6-3177bis-48boundary-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: <2005-7-12130012.I-D@ietf.org> > >> > >> ENCODING mime > >> FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt > >> > >> --OtherAccess > >> Content-Type: Message/External-body; > >> name="draft-narten-ipv6-3177bis-48boundary-00.txt"; > >> site="ftp.ietf.org"; access-type="anon-ftp"; > >> directory="internet-drafts" > >> > >> Content-Type: text/plain > >> Content-ID: <2005-7-12130012.I-D@ietf.org> > >> > >> > >> --OtherAccess-- > >> > >> --NextPart > >> Content-Type: text/plain; charset="us-ascii" > >> MIME-Version: 1.0 > >> Content-Transfer-Encoding: 7bit > >> Content-Disposition: inline > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www1.ietf.org/mailman/listinfo/i-d-announce > >> > >> --NextPart-- > >> > >> ------- End of Forwarded Message > >> > >> -------------------------------------------------------------------- > >> 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 > > Barcelona 2005 Global IPv6 Summit > Information available at: > http://www.ipv6-es.com > > 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 Mon Jul 18 14:03:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuZxe-0006tX-Mn; Mon, 18 Jul 2005 14:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuZxc-0006tC-PU for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 14:03:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01997 for ; Mon, 18 Jul 2005 14:03:23 -0400 (EDT) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuaR5-0002LP-JE for ipv6@ietf.org; Mon, 18 Jul 2005 14:33:52 -0400 Received: from [10.10.10.100] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001153083.msg for ; Mon, 18 Jul 2005 20:04:29 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 18 Jul 2005 20:02:45 +0200 From: JORDI PALET MARTINEZ To: , "ipv6@ietf.org" Message-ID: In-Reply-To: <200507181753.NAA01381@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es 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 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Processed: consulintel.es, Mon, 18 Jul 2005 20:04:33 +0200 X-MDAV-Processed: consulintel.es, Mon, 18 Jul 2005 20:04:34 +0200 X-Spam-Score: 2.2 (++) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: 7bit Cc: Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I was thinking in a PPP link or PDP context, I'm not really sure if they allow (at least today, but protocol definition), to use a prefix instead of an address. Also for tunnel end points, where I think the recommendation is /126, but some people still use /128, etc. Regards, Jordi > De: Tony Hain > Responder a: > Fecha: Mon, 18 Jul 2005 10:50:52 -0700 > Para: , , > > Asunto: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > The operator never should know if the device has a backside interface, so > the argument about /128 being valid is also wrong (/128's are the fastest > track to an IPv6 NAT that there is). From the perspective of the operator > they are selling access via a link, what the consumer does behind the device > connected to the link (other than resell it) is not their business. They > should be set up to allocate a prefix shorter than /64 in all cases. > > Tony > > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> JORDI PALET MARTINEZ >> Sent: Saturday, July 16, 2005 1:39 PM >> To: global-v6@lists.apnic.net; ipv6@ietf.org >> Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >> >> I tend to agree with this. >> >> I see situations for assigning a /128 when a unique device is connected, >> which is not going to route anything else, but once it has other >> interfaces >> (which is the most common case and will become more and more often) ... >> >> Regards, >> Jordi >> >> >> >> >>> De: Tony Hain >>> Responder a: >>> Fecha: Fri, 15 Jul 2005 17:40:24 -0700 >>> Para: 'Thomas Narten' , >>> Asunto: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >>> >>> I said part of this on the ARIN PPML list but thought it should be >> repeated >>> here. >>> >>> A /64 allocation never makes any sense. The claims about a PDA only >> needing >>> one assume that it will never be dropped into a cradle of a vehicle >> suddenly >>> enabling various subnets (freight environmental or inventory monitor, >>> dispatch service) to reach out or be reached with independent access >>> controls. A /64 puts the carrier in the position of telling the customer >>> they can't build anything more than a single lan, where a /60 removes >> that >>> limitation with effectively the same impact on space utilization. >>> >>> We bumped into another version of this when thinking through some of the >>> issues with cable. The MSO's appear to be focusing around a prefix being >> the >>> unit of allocation to a customer. All well and good until we get the 'a >> /64 >>> is more than enough space' discussion. The issue crystallized when the >>> discussion included a separate subnet for cable devices in the home to >>> communicate locally. Since the MSO has bought into the concept of a >> prefix >>> maps to a customer, having independent /64's breaks the allocation and >>> management model. The conservation mindset clashes with the simplified >>> management mindset and documents with wording like this are not helping. >>> >>> This draft really needs to remove the discussion about a /64 being >>> appropriate for anything from an allocation perspective. There is no >> serious >>> technical need for the draft to begin with, but if it exists it should >> point >>> out that a /60 is the longest prefix that allows customers to build >> networks >>> with multiple links (specifically technologies that don't bridge) and >> maps >>> cleanly onto the reverse delegation name tree. >>> >>> Tony >>> >>> >>>> -----Original Message----- >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >>>> Thomas Narten >>>> Sent: Wednesday, July 13, 2005 2:44 PM >>>> To: ipv6@ietf.org >>>> Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >>>> >>>> Here's an ID for consideration by the IPv6 WG. >>>> >>>> Background: >>>> >>>> Discussion on the more general topic took place at the April ARIN and >>>> May RIPE meetings. A good summary of those presentations can be found >>>> at: >>>> >>>> http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary- >>>> wed-ipv6-roundtable-report.pdf >>>> >>>> A more general discussion of the overall topic of IPv6 address >>>> allocation considerations (the /48 boundary topic is just one piece of >>>> a larger puzzle) can be found at: >>>> >>>> http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6- >>>> considerations-00.txt >>>> >>>> Thomas >>>> >>>> ------- Forwarded Message >>>> >>>> From: Internet-Drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> Date: Tue, 12 Jul 2005 15:50:03 -0400 >>>> Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >>>> Reply-To: internet-drafts@ietf.org >>>> >>>> --NextPart >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : IPv6 Address Allocation to End Sites >>>> Author(s) : T. Narten, et al. >>>> Filename : draft-narten-ipv6-3177bis-48boundary-00.txt >>>> Pages : 8 >>>> Date : 2005-7-12 >>>> >>>> This document revisits the IAB/IESG recommendations on the >> assignment >>>> of IPv6 address space to end sites. Specifically, it indicates that >>>> changing the default end-site assignment for typical home and SOHO >>>> sites from /48 to /56 is consistent with the goals of IPv6 and RFC >>>> 3177. Although it is for the RIR community to make adjustments to >> the >>>> IPv6 address space allocation and end site assignment policies, the >>>> IETF community would be comfortable with RIRs changing the default >>>> assignment size to /56 for smaller end sites. This document >> obsoletes >>>> RFC 3177 and reclassifies it as historic. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis- >> 48boundary- >>>> 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-narten-ipv6-3177bis-48boundary-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-narten-ipv6-3177bis-48boundary-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: <2005-7-12130012.I-D@ietf.org> >>>> >>>> ENCODING mime >>>> FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt >>>> >>>> --OtherAccess >>>> Content-Type: Message/External-body; >>>> name="draft-narten-ipv6-3177bis-48boundary-00.txt"; >>>> site="ftp.ietf.org"; access-type="anon-ftp"; >>>> directory="internet-drafts" >>>> >>>> Content-Type: text/plain >>>> Content-ID: <2005-7-12130012.I-D@ietf.org> >>>> >>>> >>>> --OtherAccess-- >>>> >>>> --NextPart >>>> Content-Type: text/plain; charset="us-ascii" >>>> MIME-Version: 1.0 >>>> Content-Transfer-Encoding: 7bit >>>> Content-Disposition: inline >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/i-d-announce >>>> >>>> --NextPart-- >>>> >>>> ------- End of Forwarded Message >>>> >>>> -------------------------------------------------------------------- >>>> 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 >> >> Barcelona 2005 Global IPv6 Summit >> Information available at: >> http://www.ipv6-es.com >> >> 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 Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com 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 Mon Jul 18 14:35:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuaSi-0006Kt-BC; Mon, 18 Jul 2005 14:35:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuaSg-0006Kj-RV for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 14:35:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04378 for ; Mon, 18 Jul 2005 14:35:29 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duaw9-0003ob-Fh for ipv6@ietf.org; Mon, 18 Jul 2005 15:05:58 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6II3WM26069 for ; Mon, 18 Jul 2005 11:03:32 -0700 X-mProtect: <200507181803> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp166122.americas.nokia.com (10.241.166.122, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdQHPcWr; Mon, 18 Jul 2005 11:03:31 PDT Message-Id: <6.2.1.2.2.20050718103023.02890cd0@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 18 Jul 2005 11:35:10 -0700 To: IPv6 WG From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This starts a one week IPv6 working group last call on advancing Title : Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta Filename : draft-ietf-ipngwg-icmp-v3-07.txt Pages : 27 Date : 2005-7-14 to Draft standard. Please send substantive comments to the IPv6 mailing list. Editorial comments can be sent to the authors. The changes in this draft were to resolve issues raised by IESG area directors during the IESG evaluation. As of the time this was sent, all but one of Discuss comments have been cleared and we are waiting to hear from remaining AD. The IPv6 w.g. chairs have reviewed the changes and think they are fine, but wanted to working group to review them. The IESG discuss comments can be found on the IETF document tracker at: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=4420&rfc_flag=0 This last call will end on July 25, 2005. Regards, Bob & Brian IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 18 15:14:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dub4o-0007RJ-6m; Mon, 18 Jul 2005 15:14:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dub4m-0007RE-2w for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 15:14:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07512 for ; Mon, 18 Jul 2005 15:14:48 -0400 (EDT) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DubYC-0005B0-Lg for ipv6@ietf.org; Mon, 18 Jul 2005 15:45:18 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Mon, 18 Jul 2005 19:14:47 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Mon, 18 Jul 2005 19:14:22 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Jul 2005 14:13:54 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt Thread-Index: AcWLzNcRsqlYGxxiQ76PA2qxaFPvtQ== From: "Pashby, Ronald W CTR NSWCDD-B35" To: X-OriginalArrivalTime: 18 Jul 2005 19:13:55.0075 (UTC) FILETIME=[D73F0D30:01C58BCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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="===============1452387626==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1452387626== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58BCC.D6FAB5A4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58BCC.D6FAB5A4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the second paragraph of section 5 it reads: "Compute the MD5 hash [11] of the first label of the Subject Name -- the = portion beginning with the first one-octet length field and up to, but = excluding, any subsequent length field. Append the first 32 bits of that = 128-bit hash to the prefix FF02:0:0:0:0: 2::/96. The resulting multicast = address will be termed the "NI Group Address" for the name. A node will = support an "NI Group Address" for each associated Subject Name." This does not follow the intent of RFC3307. RFC3307 intended for = dynamically assigned multicast ids be forced into the range from = 0x80000000 - 0xFFFFFFFF, to avoid overlapping at the layer 2 with = globally assigned addresses. Take for instance that a name hashes to = 0x00000001 (there is nothing that would hinder this) then every host = would receive it at the layer 2 level and would have to be processed at = the IP level. Likewise, the same would occur for any other IANA assigned = addresses.=20 RFC3307 states that if the T bit is (transient address) the MSB shall be = set. It does not state that if the T bit is not set, that the MSB shall = be reset. Clearly these addresses are transient addresses and should be = treated as such in creating the 32 bit multicast id. I think it should at least set the MSB of the 32 bit hash value. There = is a recommendation that the high byte be set to 0xFF to keep it in the = same range as the solicited node addresses (at the layer 2 boundary) = since it is achieving a similar purpose. I understand that this change will break backward compatibility, but it = is better to fix it now than cause further non-conformant issues that = may cause problems later. ------_=_NextPart_001_01C58BCC.D6FAB5A4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt

In the second paragraph of section 5 it = reads:
"Compute the MD5 hash [11] of = the first label of the Subject Name -- the portion beginning with the = first one-octet length field and up to, but excluding, any subsequent = length field. Append the first 32 bits of that 128-bit hash to the = prefix FF02:0:0:0:0: 2::/96. The resulting multicast address will be = termed the "NI Group Address" for the name. A node will = support an "NI Group Address" for each associated Subject = Name."

This does not follow the intent of = RFC3307. RFC3307 intended for dynamically assigned multicast ids be = forced into the range from 0x80000000 - 0xFFFFFFFF, to avoid overlapping = at the layer 2 with globally assigned addresses. Take for instance that = a name hashes to 0x00000001 (there is nothing that would hinder this) = then every host would receive it at the layer 2 level and would have to = be processed at the IP level. Likewise, the same would occur for any = other IANA assigned addresses.

RFC3307 states that if the T bit is = (transient address) the MSB shall be set. It does not state that if the = T bit is not set, that the MSB shall be reset. Clearly these addresses = are transient addresses and should be treated as such in creating the 32 = bit multicast id.

I think it should at least set the MSB = of the 32 bit hash value. There is a recommendation that the high byte = be set to 0xFF to keep it in the same range as the solicited node = addresses (at the layer 2 boundary) since it is achieving a similar = purpose.

I understand that this change will = break backward compatibility, but it is better to fix it now than cause = further non-conformant issues that may cause problems later.

------_=_NextPart_001_01C58BCC.D6FAB5A4-- --===============1452387626== 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 -------------------------------------------------------------------- --===============1452387626==-- From ipv6-bounces@ietf.org Mon Jul 18 17:09:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DucrR-0006gU-2d; Mon, 18 Jul 2005 17:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DucrP-0006gM-0X for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 17:09:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28917 for ; Mon, 18 Jul 2005 17:09:08 -0400 (EDT) Received: from lacnic.net.uy ([200.40.228.66] helo=micron.lacnic.net.uy) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DudKq-0005Pb-7i for ipv6@ietf.org; Mon, 18 Jul 2005 17:39:40 -0400 Received: from [127.0.0.1] (27.Red-217-126-162.pooles.rima-tde.net [217.126.162.27]) by micron.lacnic.net.uy (8.13.1/8.13.1) with ESMTP id j6ILKEHn028352; Mon, 18 Jul 2005 18:20:22 -0300 (UYT) (envelope-from raul@lacnic.net) Message-ID: <42DC1A21.9070400@lacnic.net> Date: Mon, 18 Jul 2005 18:07:45 -0300 From: Raul Echeberria User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: global-v6@lists.apnic.net, "ipv6@ietf.org" References: <200507161220.j6GCKFXD004875@cichlid.raleigh.ibm.com> In-Reply-To: <200507161220.j6GCKFXD004875@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Status: No, score=0.4 required=5.0 tests=DNS_FROM_RFC_ABUSE autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on micron.lacnic.net.uy X-Lacnic.uy-MailScanner-Information: Please contact the ISP for more information X-Lacnic.uy-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: raul@lacnic.net Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by micron.lacnic.net.uy id j6ILKEHn028352 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thomas Narten wrote: >Ito-san, > >You raise some good questions. > > =20 > >>I have been observing the current discussion on "reviewing >>the current policies and address allocation practices". >>Then, I felt that we should resort what a real issue is. >>Why do we need to change HD-Ratio? >> =20 >> > >To ensure that we really have plenty of IPv6 addresses to last us 100+ >years. Consider IPv4. Have we already run out? Some say effectively >yes, because now that we see that we will run out, addressing policy >has changed (to increase conservation) and it has become harder to get >them. Hence, we've been forced to change our behavior in response to a >decrease in the supply. > =20 > Thomas: I don't agree with your perception regarding IPv4 policies what seems=20 to be the base of your argument here. Maybe it is more difficult to get IPv4 addresses now than in the=20 earlies `90, but I don't agree that the policies developed in the RIR's=20 forums in the last couple of yesars are more conservatives. On the other hand, there are many people (including myself) that share=20 the concern taht it could happen the same that already happened with=20 IPv4 during the early deployment of Internet, causing unfairness in the=20 size of allocations of IP addresses. I tend to agree with the idea behind your draft, but not with that you=20 said here. Ra=FAl -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 18 17:09:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ducs1-0006qb-Sq; Mon, 18 Jul 2005 17:09:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ducrv-0006pl-QE for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 17:09:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28956 for ; Mon, 18 Jul 2005 17:09:41 -0400 (EDT) Message-Id: <200507182109.RAA28956@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DudLN-0005R7-PW for ipv6@ietf.org; Mon, 18 Jul 2005 17:40:13 -0400 Received: from eaglet (127.0.0.1:2237) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 18 Jul 2005 14:07:57 -0700 From: "Tony Hain" To: , , Date: Mon, 18 Jul 2005 14:05:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWLwwd2nkkKRx4SR9y4gMlG+zEYwQAFYfzA X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Content-Transfer-Encoding: 7bit Cc: Subject: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org PPP is a link technology for connecting the consumer device to the SP router. Not to be advertising, but http://www.cisco.com/en/US/products/hw/routers/ps272/index.html would take any offered PDP context as an interesting link that might have a route to someplace useful at the other end. The point is it doesn't matter if that consumer device is an endpoint or a router; the carrier sees a logical link to a customer. What the customer does behind the device on the other end of that link is outside the carrier's realm of concern. Even if they think they know, widespread use of NAT proves that they don't. So rather than look at this as a role specific device connecting to a limited scope service, the carriers need to pay attention to the fact that the consumer edge device is in control of the actual application, and any barriers just create a market for technologies to circumvent them. Yes, there are no technical problems with long prefixes. The problem with long prefixes is the operational fall out at the other end. If business models get built around very long prefixes, people will demand a one-time-cost device to use the low continuing cost long prefix as a means to mitigate the costs of doing it right to start with. IETF documents should not recommend anything longer than a /60 at the demarc between a service provider and customer. It is not the IETF's job to define business models, but outlining the consequences of specific approaches is a responsibility. Tony > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > JORDI PALET MARTINEZ > Sent: Monday, July 18, 2005 11:03 AM > To: global-v6@lists.apnic.net; ipv6@ietf.org > Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > I was thinking in a PPP link or PDP context, I'm not really sure if they > allow (at least today, but protocol definition), to use a prefix instead > of > an address. Also for tunnel end points, where I think the recommendation > is > /126, but some people still use /128, etc. > > Regards, > Jordi > > > > > > De: Tony Hain > > Responder a: > > Fecha: Mon, 18 Jul 2005 10:50:52 -0700 > > Para: , , > > > > Asunto: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > > > The operator never should know if the device has a backside interface, > so > > the argument about /128 being valid is also wrong (/128's are the > fastest > > track to an IPv6 NAT that there is). From the perspective of the > operator > > they are selling access via a link, what the consumer does behind the > device > > connected to the link (other than resell it) is not their business. They > > should be set up to allocate a prefix shorter than /64 in all cases. > > > > Tony > > > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > >> JORDI PALET MARTINEZ > >> Sent: Saturday, July 16, 2005 1:39 PM > >> To: global-v6@lists.apnic.net; ipv6@ietf.org > >> Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > >> > >> I tend to agree with this. > >> > >> I see situations for assigning a /128 when a unique device is connected, > >> which is not going to route anything else, but once it has other > >> interfaces > >> (which is the most common case and will become more and more often) ... > >> > >> Regards, > >> Jordi > >> > >> > >> > >> > >>> De: Tony Hain > >>> Responder a: > >>> Fecha: Fri, 15 Jul 2005 17:40:24 -0700 > >>> Para: 'Thomas Narten' , > >>> Asunto: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > >>> > >>> I said part of this on the ARIN PPML list but thought it should be > >> repeated > >>> here. > >>> > >>> A /64 allocation never makes any sense. The claims about a PDA only > >> needing > >>> one assume that it will never be dropped into a cradle of a vehicle > >> suddenly > >>> enabling various subnets (freight environmental or inventory monitor, > >>> dispatch service) to reach out or be reached with independent access > >>> controls. A /64 puts the carrier in the position of telling the > customer > >>> they can't build anything more than a single lan, where a /60 removes > >> that > >>> limitation with effectively the same impact on space utilization. > >>> > >>> We bumped into another version of this when thinking through some of > the > >>> issues with cable. The MSO's appear to be focusing around a prefix > being > >> the > >>> unit of allocation to a customer. All well and good until we get the > 'a > >> /64 > >>> is more than enough space' discussion. The issue crystallized when the > >>> discussion included a separate subnet for cable devices in the home to > >>> communicate locally. Since the MSO has bought into the concept of a > >> prefix > >>> maps to a customer, having independent /64's breaks the allocation and > >>> management model. The conservation mindset clashes with the simplified > >>> management mindset and documents with wording like this are not > helping. > >>> > >>> This draft really needs to remove the discussion about a /64 being > >>> appropriate for anything from an allocation perspective. There is no > >> serious > >>> technical need for the draft to begin with, but if it exists it should > >> point > >>> out that a /60 is the longest prefix that allows customers to build > >> networks > >>> with multiple links (specifically technologies that don't bridge) and > >> maps > >>> cleanly onto the reverse delegation name tree. > >>> > >>> Tony > >>> > >>> > >>>> -----Original Message----- > >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of > >>>> Thomas Narten > >>>> Sent: Wednesday, July 13, 2005 2:44 PM > >>>> To: ipv6@ietf.org > >>>> Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > >>>> > >>>> Here's an ID for consideration by the IPv6 WG. > >>>> > >>>> Background: > >>>> > >>>> Discussion on the more general topic took place at the April ARIN and > >>>> May RIPE meetings. A good summary of those presentations can be > found > >>>> at: > >>>> > >>>> http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50- > plenary- > >>>> wed-ipv6-roundtable-report.pdf > >>>> > >>>> A more general discussion of the overall topic of IPv6 address > >>>> allocation considerations (the /48 boundary topic is just one piece > of > >>>> a larger puzzle) can be found at: > >>>> > >>>> http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6- > >>>> considerations-00.txt > >>>> > >>>> Thomas > >>>> > >>>> ------- Forwarded Message > >>>> > >>>> From: Internet-Drafts@ietf.org > >>>> To: i-d-announce@ietf.org > >>>> Date: Tue, 12 Jul 2005 15:50:03 -0400 > >>>> Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > >>>> Reply-To: internet-drafts@ietf.org > >>>> > >>>> --NextPart > >>>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>>> directories. > >>>> > >>>> > >>>> Title : IPv6 Address Allocation to End Sites > >>>> Author(s) : T. Narten, et al. > >>>> Filename : draft-narten-ipv6-3177bis-48boundary-00.txt > >>>> Pages : 8 > >>>> Date : 2005-7-12 > >>>> > >>>> This document revisits the IAB/IESG recommendations on the > >> assignment > >>>> of IPv6 address space to end sites. Specifically, it indicates > that > >>>> changing the default end-site assignment for typical home and SOHO > >>>> sites from /48 to /56 is consistent with the goals of IPv6 and RFC > >>>> 3177. Although it is for the RIR community to make adjustments to > >> the > >>>> IPv6 address space allocation and end site assignment policies, > the > >>>> IETF community would be comfortable with RIRs changing the default > >>>> assignment size to /56 for smaller end sites. This document > >> obsoletes > >>>> RFC 3177 and reclassifies it as historic. > >>>> > >>>> A URL for this Internet-Draft is: > >>>> http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis- > >> 48boundary- > >>>> 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-narten-ipv6-3177bis-48boundary-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-narten-ipv6-3177bis-48boundary-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: <2005-7-12130012.I-D@ietf.org> > >>>> > >>>> ENCODING mime > >>>> FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt > >>>> > >>>> --OtherAccess > >>>> Content-Type: Message/External-body; > >>>> name="draft-narten-ipv6-3177bis-48boundary-00.txt"; > >>>> site="ftp.ietf.org"; access-type="anon-ftp"; > >>>> directory="internet-drafts" > >>>> > >>>> Content-Type: text/plain > >>>> Content-ID: <2005-7-12130012.I-D@ietf.org> > >>>> > >>>> > >>>> --OtherAccess-- > >>>> > >>>> --NextPart > >>>> Content-Type: text/plain; charset="us-ascii" > >>>> MIME-Version: 1.0 > >>>> Content-Transfer-Encoding: 7bit > >>>> Content-Disposition: inline > >>>> > >>>> _______________________________________________ > >>>> I-D-Announce mailing list > >>>> I-D-Announce@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/i-d-announce > >>>> > >>>> --NextPart-- > >>>> > >>>> ------- End of Forwarded Message > >>>> > >>>> -------------------------------------------------------------------- > >>>> 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 > >> > >> Barcelona 2005 Global IPv6 Summit > >> Information available at: > >> http://www.ipv6-es.com > >> > >> 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 > > Barcelona 2005 Global IPv6 Summit > Information available at: > http://www.ipv6-es.com > > 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 Mon Jul 18 19:47:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DufKo-0004NO-VH; Mon, 18 Jul 2005 19:47:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DufKm-0004JW-H1 for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 19:47:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29654 for ; Mon, 18 Jul 2005 19:47:37 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DufoD-00014s-4I for ipv6@ietf.org; Mon, 18 Jul 2005 20:18:10 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DufKI-0000qO-AS; Tue, 19 Jul 2005 00:47:10 +0100 Message-ID: <42DC3FC0.4070805@dial.pipex.com> Date: Tue, 19 Jul 2005 00:48:16 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pashby, Ronald W CTR NSWCDD-B35" References: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> In-Reply-To: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Consider: - The primary point of RFC3307 is to make sure that you can get a unique IPv6 multicast address - The Layer 2 non-clash is a bonus. - The addresses are (probably) not taken from the spaces to which RFC3307 applies (they are 'traditional' P=0 addresses - I believe the intent was that RFC3307 only applied to addresses for which the 80 bit reserved field is 0 as defined in the RFC2373 version of the IPv6 address architecture although this is not totally clear) - All nodes have to be able to disambiguate multicast addresses at the IP level as there is already a risk of clashes at Layer 2 (however small) (e.g., between a solicited node address and an assigned dynamic address.) - The chance of a Layer 2 clash with a bad case like the all-nodes address (asuming MD5 is any good!) is not exactly large So I think the risk of a severe performance hit is not going to be very large. Also from a logical point of view it is not clear that these are dynamically assigned - they exist whether any node is actually using them - one could therefore argue for some other MSB values if RFC3307 applied, but I think it is fairly clear that RFC3307 does not apply to them. Although the relevant section of the addressing arch has now disappeared so exactly what the scope of 3307 ought to be is maybe no longer clear. All in all I can't see any real justification for this change. Regards, Elwyn Pashby, Ronald W CTR NSWCDD-B35 wrote: > In the second paragraph of section 5 it reads: > "Compute the MD5 hash [11] of the first label of the Subject Name -- > the portion beginning with the first one-octet length field and up to, > but excluding, any subsequent length field. Append the first 32 bits > of that 128-bit hash to the prefix FF02:0:0:0:0: 2::/96. The resulting > multicast address will be termed the "NI Group Address" for the name. > A node will support an "NI Group Address" for each associated Subject > Name." > > This does not follow the intent of RFC3307. RFC3307 intended for > dynamically assigned multicast ids be forced into the range from > 0x80000000 - 0xFFFFFFFF, to avoid overlapping at the layer 2 with > globally assigned addresses. Take for instance that a name hashes to > 0x00000001 (there is nothing that would hinder this) then every host > would receive it at the layer 2 level and would have to be processed > at the IP level. Likewise, the same would occur for any other IANA > assigned addresses. > > RFC3307 states that if the T bit is (transient address) the MSB shall > be set. It does not state that if the T bit is not set, that the MSB > shall be reset. Clearly these addresses are transient addresses and > should be treated as such in creating the 32 bit multicast id. > > I think it should at least set the MSB of the 32 bit hash value. There > is a recommendation that the high byte be set to 0xFF to keep it in > the same range as the solicited node addresses (at the layer 2 > boundary) since it is achieving a similar purpose. > > I understand that this change will break backward compatibility, but > it is better to fix it now than cause further non-conformant issues > that may cause problems later. > >------------------------------------------------------------------------ > >-------------------------------------------------------------------- >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 Jul 19 04:03:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dun54-0006ra-7n; Tue, 19 Jul 2005 04:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXuz-00072j-Dj for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 11:52:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23256 for ; Mon, 18 Jul 2005 11:52:31 -0400 (EDT) Received: from rip.psg.com ([147.28.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuYON-0002Oi-PS for ipv6@ietf.org; Mon, 18 Jul 2005 12:23:00 -0400 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DuXup-000AGz-5y; Mon, 18 Jul 2005 15:52:23 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DuXuo-000KcP-IX; Mon, 18 Jul 2005 05:52:22 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17115.53300.981765.534936@roam.psg.com> Date: Mon, 18 Jul 2005 05:52:20 -1000 To: Kosuke Ito References: <200507161220.j6GCKFXD004875@cichlid.raleigh.ibm.com> <42DBC87C.5070103@bugest.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Jul 2005 04:03:57 -0400 Cc: Thomas Narten , "ipv6@ietf.org" , global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > We agree to go more liberal when we set the current policy. > But I still believe that starting of allocating /2x size > to requesting ISPs who has nothing but only because they > have IPv4 customer is, I think, too far liberal. > Is this the sound model that ISP never come back to RIR > for sub-allocation? Is this not against the basics of > address allocation that address provides when it is needed? there has been a long history of the ivtf v6 designers' view of the operational/social issues. essentially, it is based on a belief that the internet is severely hampered by users having to go to evil isps for ip space, isps having to go to evil rirs for address space, and recently, rirs having to go to the evil iana for address space. if only ip address space was freely available without any operational administratriva, ipv6 would be wildly successful and the world would be saved. personally, i am most enamored of the next-stage model, where isps do not have to actually have all those messy circuits to be able to deliver packets. randy -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 19 05:07:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duo4q-00005d-Ua; Tue, 19 Jul 2005 05:07:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duo4o-00005S-Sa for ipv6@megatron.ietf.org; Tue, 19 Jul 2005 05:07:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22572 for ; Tue, 19 Jul 2005 05:07:43 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuoYN-0003sS-Sq for ipv6@ietf.org; Tue, 19 Jul 2005 05:38:21 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 8484049D9C; Tue, 19 Jul 2005 11:07:32 +0200 (CEST) Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp03.uc3m.es (Postfix) with ESMTP id 9038A49D4D; Tue, 19 Jul 2005 11:07:26 +0200 (CEST) In-Reply-To: <9fa1a200dfc86ec0749a3641f57e0dbb@it.uc3m.es> References: <42D67A29.9030100@bugest.net> <12e46a78a25fbbbafb26b1b4a5a38602@it.uc3m.es> <42DBAAB4.30205@bugest.net> <9fa1a200dfc86ec0749a3641f57e0dbb@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Tue, 19 Jul 2005 11:07:30 +0200 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Kosuke Ito , ipv6@ietf.org, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>> Is it practical to change in other regions? >>>> >>> We had a discussion about IPv6 address management in the LACNIC VIII >>> meeting in Lima (30 of june 2005) and my reading of the comments of >>> the meeting is that they are pretty much in line with the >>> considerations expressed by Thomas in his drafts. >> >> Thank you. >> How many acctual/commercial assignments have been made (or >> registered) in LACNIC area? > > i will forward this question to lacnic people > LACNIC people send the following information w.r.t. IPv6 allocations in the lacnic region: I guess is similar to the one included in the web page sent by Jeroen regards, marcelo lacnic|MX|ipv6|2001:1200::|32|20030110|allocated lacnic|MX|ipv6|2001:1208::|32|20030203|allocated lacnic|MX|ipv6|2001:1210::|32|20040924|allocated lacnic|MX|ipv6|2001:1218::|32|20050629|allocated lacnic|BR|ipv6|2001:12e0::|32|20040702|allocated lacnic|BR|ipv6|2001:12e8::|32|20040726|allocated lacnic|BR|ipv6|2001:12f0::|32|20031028|allocated lacnic|BR|ipv6|2001:12f8::|48|20041202|allocated lacnic|BR|ipv6|2001:12ff::|32|20030728|allocated lacnic|PE|ipv6|2001:1300::|32|20050711|allocated lacnic|DO|ipv6|2001:1308::|32|20030612|allocated lacnic|CL|ipv6|2001:1310::|32|20030821|allocated lacnic|AR|ipv6|2001:1318::|32|20031124|allocated lacnic|PY|ipv6|2001:1320::|32|20040527|allocated lacnic|UY|ipv6|2001:1328::|32|20040720|allocated lacnic|CR|ipv6|2001:1330::|32|20041104|allocated lacnic|VE|ipv6|2001:1338::|32|20041123|allocated lacnic|CU|ipv6|2001:1340::|32|20050406|allocated lacnic|UY|ipv6|2001:1348::|32|20050419|allocated lacnic|VE|ipv6|2001:1350::|32|20050520|allocated lacnic|CU|ipv6|2001:1358::|32|20050629|allocated lacnic|GT|ipv6|2001:1360::|32|20050711|allocated lacnic|PA|ipv6|2001:1368::|32|20050706|allocated lacnic|HT|ipv6|2001:1370::|32|20050706|allocated lacnic|BO|ipv6|2001:1378::|32|20050706|allocated lacnic|PE|ipv6|2001:1380::|32|20050712|allocated lacnic|PE|ipv6|2001:1388::|32|20050714|allocated lacnic|AR|ipv6|2001:1390::|32|20050715|allocated lacnic|AR|ipv6|2001:1398::|32|20050718|allocated -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 19 06:15:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dup4B-00018j-V2; Tue, 19 Jul 2005 06:11:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dup4A-00017d-P1 for ipv6@megatron.ietf.org; Tue, 19 Jul 2005 06:11:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27128 for ; Tue, 19 Jul 2005 06:11:08 -0400 (EDT) Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DupXf-0006qA-CB for ipv6@ietf.org; Tue, 19 Jul 2005 06:41:47 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1Dup3q-0002Wm-Sr for ipv6@ietf.org; Tue, 19 Jul 2005 11:10:51 +0100 Message-ID: <42DCD1EB.3000600@dial.pipex.com> Date: Tue, 19 Jul 2005 11:11:55 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPv6 WG References: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> In-Reply-To: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Some comments: Substantive: s4: Code 1 bullet point: The 'Supported Qtypes' query disappeared from the rest of the memo some time ago. s5: para 5: Is the intended effect of the last sentence (defaulting to accepting all link-local multicast addresses that have been joined) that sending a NOOP query to (for example) the all-nodes (or all routers) link local multicast address will elicit a reply from *every* relevant node on the link that isn't explicitly configured to ignore these addresses? If this is the intended behaviour then I think it would be useful to put the example in so that people understand what the implication is. Presumably it is also a quick way of finding out which nodes are admitting to listening to a given multicast address. s5/References: The MD5 Hash ref [11] should be normative. s6.1: '...and incidentally happens to reveal whether the Queried Address was an anycast address.' With recent changes that allow anycast addresses as sources is this comment any longer true? s6.2: Notice that the compression algorithm is fractionally less useful than the original because the pointer can't point to as many places in the label because of the initial offset. I'm sure there must have been a reason for doing it this way once ;-) s6.4.1: [wish list] It occurs to me with the mention of tunnels that a Qtype to find out about the addresses associated with (e.g.) configured tunnels would be useful (v6 in v4 for example). s7: I wonder if IETF concensus is a little strong for Codes and Qtypes for an experimental protocol? s7: Presumably IANA is being asked to establish a registry for the Qtypes.. this isn't explicit currently. Editorial nits: s1/2: I would use 'mechanisms' instead of 'mechanics'. s5: para 8: 'If an answer is refused, the Responder may send an NI Reply with ICMPv6 Code = 1 and no Reply Data.' This is a policy choice and I think this should be made clear: s/the Responder may send/depending on local policy the Responder can elect to silently discard the query or send/ s6.2: It would be useful to quote the section numbers in RFC1035 for the DNS wire format (s3.1) and the compression algorithm (s4.1.4). Regards, Elwyn Bob Hinden wrote: > This starts a two week IPv6 working group last call on advancing: > > Title : IPv6 Node Information Queries > Author(s) : M. Crawford, B. Haberman > Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt > Pages : 14 > Date : 2005-7-14 > > to Experimental. Please send substantive comments to the IPv6 mailing > list. Editorial comments can be sent to the authors. > > This last call will end on July 29, 2005. > > Regards, > Bob & Brian > IPv6 WG co-chairs > > > > -------------------------------------------------------------------- > 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 Jul 19 06:36:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DupSH-0008Bq-6Q; Tue, 19 Jul 2005 06:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DupSE-0008Bd-Hu for ipv6@megatron.ietf.org; Tue, 19 Jul 2005 06:36:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29238 for ; Tue, 19 Jul 2005 06:35:59 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dupvl-00080U-7y for ipv6@ietf.org; Tue, 19 Jul 2005 07:06:38 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DupRu-0006zr-M5 for ipv6@ietf.org; Tue, 19 Jul 2005 11:35:43 +0100 Message-ID: <42DCD7BF.1070603@dial.pipex.com> Date: Tue, 19 Jul 2005 11:36:47 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPv6 WG References: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> In-Reply-To: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Subject: Re: IPv6 WG Last Call: with PS X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org PS s7: The IANA considerations should refer to the IANA considerations in 2463bis (draft-ietf-ipngwg-icmp-v3-07.txt). Some comments: Substantive: s4: Code 1 bullet point: The 'Supported Qtypes' query disappeared from the rest of the memo some time ago. s5: para 5: Is the intended effect of the last sentence (defaulting to accepting all link-local multicast addresses that have been joined) that sending a NOOP query to (for example) the all-nodes (or all routers) link local multicast address will elicit a reply from *every* relevant node on the link that isn't explicitly configured to ignore these addresses? If this is the intended behaviour then I think it would be useful to put the example in so that people understand what the implication is. Presumably it is also a quick way of finding out which nodes are admitting to listening to a given multicast address. s5/References: The MD5 Hash ref [11] should be normative. s6.1: '...and incidentally happens to reveal whether the Queried Address was an anycast address.' With recent changes that allow anycast addresses as sources is this comment any longer true? s6.2: Notice that the compression algorithm is fractionally less useful than the original because the pointer can't point to as many places in the label because of the initial offset. I'm sure there must have been a reason for doing it this way once ;-) s6.4.1: [wish list] It occurs to me with the mention of tunnels that a Qtype to find out about the addresses associated with (e.g.) configured tunnels would be useful (v6 in v4 for example). s7: I wonder if IETF concensus is a little strong for Codes and Qtypes for an experimental protocol? s7: Presumably IANA is being asked to establish a registry for the Qtypes.. this isn't explicit currently. Editorial nits: s1/2: I would use 'mechanisms' instead of 'mechanics'. s5: para 8: 'If an answer is refused, the Responder may send an NI Reply with ICMPv6 Code = 1 and no Reply Data.' This is a policy choice and I think this should be made clear: s/the Responder may send/depending on local policy the Responder can elect to silently discard the query or send/ s6.2: It would be useful to quote the section numbers in RFC1035 for the DNS wire format (s3.1) and the compression algorithm (s4.1.4). Regards, Elwyn Bob Hinden wrote: > This starts a two week IPv6 working group last call on advancing: > > Title : IPv6 Node Information Queries > Author(s) : M. Crawford, B. Haberman > Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt > Pages : 14 > Date : 2005-7-14 > > to Experimental. Please send substantive comments to the IPv6 mailing > list. Editorial comments can be sent to the authors. > > This last call will end on July 29, 2005. > > Regards, > Bob & Brian > IPv6 WG co-chairs > > > > -------------------------------------------------------------------- > 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 Jul 19 07:32:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuqKb-0007D7-HG; Tue, 19 Jul 2005 07:32:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuqKZ-0007D2-HK for ipv6@megatron.ietf.org; Tue, 19 Jul 2005 07:32:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03945 for ; Tue, 19 Jul 2005 07:32:10 -0400 (EDT) Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duqo5-0002Ca-RT for ipv6@ietf.org; Tue, 19 Jul 2005 08:02:48 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DuqK4-0006Hi-2r; Tue, 19 Jul 2005 12:31:40 +0100 Message-ID: <42DCE4DC.5010207@dial.pipex.com> Date: Tue, 19 Jul 2005 12:32:44 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter References: <42D770A3.8090206@zurich.ibm.com> In-Reply-To: <42D770A3.8090206@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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: zinin@psg.com, brian@innovationslab.net, bob.hinden@nokia.com, mankin@psg.com, margaret@thingmagic.com, IPv6 Subject: Re: New Version Notification - draft-ietf-ipngwg-icmp-v3-07.txt - IANA Considerations for ICMP specifications (esp. 2461bis) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I have just been reviewing the latest version of the name lookups draft and checking the IANA considerations for that draft triggered me to look across the IANA considerations for all the ICMPv6 stuff we have in progress at present. The conclusions are: - icmp-v3 supersedes section 7 in RFC2780 and should be noted as updating RFC2780 - The IANA considerations in 2461bis need a complete rewrite - Reference icmp-v3 instead of RFC2780 - to explicitly say which ICMPv6 types it is continuing the registration for - define the registry and the policy for ND options - to say explicitly which options it is defining/continuing - Some minor changes to the name-lookups draft are covered in a separate email on its last call - 2462bis and the nd-proxy draft correctly say they have no IANA requirements. - ipv6-router-selection is correct - it will be automagically be updated to ref 2461bis hopefully! - privacy-addrs-v2 has no IANA considerations section - it needs a null one. - MLDv1 has no IANA considerations section but MLDv2 is fine although it doesn't refer to RFC2780 - SEND (RFC3971) and mipv6 (RFC3775) are all in order although they don't refer to RFC2780 Regards, Elwyn Brian E Carpenter wrote: > Hi Elwyn, can you kindly re-review this to see if your points have > been addressed? > > Thanks > > Brian > > ID Tracker wrote: > >> New version (-07) has been submitted for >> draft-ietf-ipngwg-icmp-v3-07.txt. >> http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-07.txt >> >> Sub state has been changed to AD Follow up from New Id Needed >> >> IETF Secretariat. >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 19 07:53:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duqeh-0003VO-Ua; Tue, 19 Jul 2005 07:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duqeg-0003Ra-Mk for ipv6@megatron.ietf.org; Tue, 19 Jul 2005 07:52:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05173 for ; Tue, 19 Jul 2005 07:52:33 -0400 (EDT) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dur7v-0002uZ-61 for ipv6@ietf.org; Tue, 19 Jul 2005 08:23:11 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 19 Jul 2005 11:52:33 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw13c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Tue, 19 Jul 2005 11:52:20 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) 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: Tue, 19 Jul 2005 06:51:52 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9EC873@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt Thread-Index: AcWL8zZIwcZVfZnNTOaxwZeyPmKv5QAX03iA From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Elwyn Davies" X-OriginalArrivalTime: 19 Jul 2005 11:51:52.0654 (UTC) FILETIME=[411086E0:01C58C58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org - I disagree that RFC3307 was only for Layer 3. It is clearly stated in = the Abstract and Introduction that:=20 "The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the link-layer address." If layer 2 was not the main reason not so much effort would be placed in = defining the behavior in the lower 32 bits. In fact the whole document = addresses the lower 32 bits that is mapped to layer 2. - RFC3307 is clear that it is for all multicast addresses. In the = Applicability section it states: "These guidelines are designed to be used in any environment in which IPv6 multicast addresses are delegated, assigned, or selected." - In some environments it is critical to avoid collisions if at all = possible. Even the processing at the IP layer to discard the packet = might cause a problem in time sensitive applications. There is some work = being proposed to disambiguate the solicited node addresses from other = dynamically assigned addresses. - I'm not a cryptologist, but MD5 was defined to minimize the collision = of 2 "valid" messages that are both hashed and it produces 128 bit = value. Here we are only taking 32 of those bits and we are not hashing 2 = "valid" messages and comparing the result. Therefore I would not make = any statements into the possibility of collisions. I agree that it would = seem on the surface that the probability is low. However, would you bet = your life or finances on that probability. - Now is the time to fix possible problems, not wait for them to become = problems after it becomes an RFC. -----Original Message----- From: Elwyn Davies [mailto:elwynd@dial.pipex.com] Sent: Monday, July 18, 2005 19:48 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: ipv6@ietf.org Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt Consider: - The primary point of RFC3307 is to make sure that you can get a unique = IPv6 multicast address - The Layer 2 non-clash is a bonus. - The addresses are (probably) not taken from the spaces to which=20 RFC3307 applies (they are 'traditional' P=3D0 addresses - I believe the=20 intent was that RFC3307 only applied to addresses for which the 80 bit=20 reserved field is 0 as defined in the RFC2373 version of the IPv6=20 address architecture although this is not totally clear) - All nodes have to be able to disambiguate multicast addresses at the=20 IP level as there is already a risk of clashes at Layer 2 (however=20 small) (e.g., between a solicited node address and an assigned dynamic=20 address.) - The chance of a Layer 2 clash with a bad case like the all-nodes=20 address (asuming MD5 is any good!) is not exactly large So I think the risk of a severe performance hit is not going to be very=20 large. Also from a logical point of view it is not clear that these are=20 dynamically assigned - they exist whether any node is actually using=20 them - one could therefore argue for some other MSB values if RFC3307=20 applied, but I think it is fairly clear that RFC3307 does not apply to=20 them. Although the relevant section of the addressing arch has now=20 disappeared so exactly what the scope of 3307 ought to be is maybe no=20 longer clear. All in all I can't see any real justification for this change. Regards, Elwyn Pashby, Ronald W CTR NSWCDD-B35 wrote: > In the second paragraph of section 5 it reads: > "Compute the MD5 hash [11] of the first label of the Subject Name --=20 > the portion beginning with the first one-octet length field and up to, = > but excluding, any subsequent length field. Append the first 32 bits=20 > of that 128-bit hash to the prefix FF02:0:0:0:0: 2::/96. The resulting = > multicast address will be termed the "NI Group Address" for the name.=20 > A node will support an "NI Group Address" for each associated Subject=20 > Name." > > This does not follow the intent of RFC3307. RFC3307 intended for=20 > dynamically assigned multicast ids be forced into the range from=20 > 0x80000000 - 0xFFFFFFFF, to avoid overlapping at the layer 2 with=20 > globally assigned addresses. Take for instance that a name hashes to=20 > 0x00000001 (there is nothing that would hinder this) then every host=20 > would receive it at the layer 2 level and would have to be processed=20 > at the IP level. Likewise, the same would occur for any other IANA=20 > assigned addresses. > > RFC3307 states that if the T bit is (transient address) the MSB shall=20 > be set. It does not state that if the T bit is not set, that the MSB=20 > shall be reset. Clearly these addresses are transient addresses and=20 > should be treated as such in creating the 32 bit multicast id. > > I think it should at least set the MSB of the 32 bit hash value. There = > is a recommendation that the high byte be set to 0xFF to keep it in=20 > the same range as the solicited node addresses (at the layer 2=20 > boundary) since it is achieving a similar purpose. > > I understand that this change will break backward compatibility, but=20 > it is better to fix it now than cause further non-conformant issues=20 > that may cause problems later. > >------------------------------------------------------------------------= > >-------------------------------------------------------------------- >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 Jul 19 10:51:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutRG-0000eM-9Z; Tue, 19 Jul 2005 10:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutQ8-0000Ko-4v; Tue, 19 Jul 2005 10:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20154; Tue, 19 Jul 2005 10:50:05 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dutth-0001yd-Bk; Tue, 19 Jul 2005 11:20:42 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DutQ2-0003dU-8B; Tue, 19 Jul 2005 10: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 Jul 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-2461bis-04.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: , Sender: ipv6-bounces@ietf.org 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 : Neighbor Discovery for IP version 6 (IPv6) Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-2461bis-04.txt Pages : 87 Date : 2005-7-19 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-04.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-2461bis-04.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-2461bis-04.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: <2005-7-19103843.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-2461bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-2461bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19103843.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 Jul 19 17:04:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuzGS-0002xC-PR; Tue, 19 Jul 2005 17:04:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuzGO-0002wC-A2 for ipv6@megatron.ietf.org; Tue, 19 Jul 2005 17:04:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28363 for ; Tue, 19 Jul 2005 17:04:25 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duzk4-0004TM-Aj for ipv6@ietf.org; Tue, 19 Jul 2005 17:35:09 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6JKWFp00495; Tue, 19 Jul 2005 13:32:15 -0700 X-mProtect: <200507192032> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp166122.americas.nokia.com (10.241.166.122, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd1mhLXc; Tue, 19 Jul 2005 13:32:13 PDT Message-Id: <6.2.1.2.2.20050719140026.02838650@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 19 Jul 2005 14:03:41 -0700 To: jordi.palet@consulintel.es From: Bob Hinden In-Reply-To: References: <200507160040.UAA10109@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "ipv6@ietf.org" , global-v6@lists.apnic.net Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jordi, >I see situations for assigning a /128 when a unique device is connected, >which is not going to route anything else, but once it has other interfaces >(which is the most common case and will become more and more often) ... A /128 breaks IPv6 Privacy Addresses (RFC3041). Every device needs a /64 to allow this mechanism to be used. 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 Jul 19 18:18:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv0KY-0006kZ-E9; Tue, 19 Jul 2005 18:12:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv0KV-0006g0-8h for ipv6@megatron.ietf.org; Tue, 19 Jul 2005 18:12:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01103 for ; Tue, 19 Jul 2005 18:12:44 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv0o9-0008EI-GA for ipv6@ietf.org; Tue, 19 Jul 2005 18:43:29 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA20707; Tue, 19 Jul 2005 15:12:25 -0700 (PDT) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6JMCOv15793; Tue, 19 Jul 2005 17:12:24 -0500 (CDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Jul 2005 18:12:24 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jul 2005 18:12:23 -0400 Message-ID: Thread-Topic: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt Thread-Index: AcWMqsvZo1xmWW5YSv2AfCbWr8omVQAAqoog From: "Manfredi, Albert E" To: "Bob Hinden" X-OriginalArrivalTime: 19 Jul 2005 22:12:24.0173 (UTC) FILETIME=[F0C779D0:01C58CAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, global-v6@lists.apnic.net Subject: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > A /128 breaks IPv6 Privacy Addresses (RFC3041). Every device=20 > needs a /64=20 > to allow this mechanism to be used. >=20 > Bob Alternative mechanisms could permit interface IDs to be shorter than 64 bits, for example 48 bits or far fewer than that. Interface IDs only need to be unique within a given subnet, and subnets with long prefixes could be small enough to make the uniqueness requirement easy to achieve. And also resolve the privacy concern in RFC 3041, by not creating interface IDs that are likely to be globally unique? If we're quibbling about conserving address space by assigning 56 vs 48 bit prefixes to individual sites, imagine how much more flexibility and savings could be achieved by allowing shorter interface IDs. Without imposing the restriction in RFC 3513 Section 4, and without increasing privacy concerns. No? Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 02:33:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv88f-0002j3-Ij; Wed, 20 Jul 2005 02:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv88d-0002gL-AQ for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 02:33:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02668 for ; Wed, 20 Jul 2005 02:33:01 -0400 (EDT) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv8cO-0000ec-F1 for ipv6@ietf.org; Wed, 20 Jul 2005 03:03:50 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j6K6WlSk310854 for ; Wed, 20 Jul 2005 06:32:47 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6K6Wlx0281160 for ; Wed, 20 Jul 2005 07:32:47 +0100 Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j6K6Wk2h015604 for ; Wed, 20 Jul 2005 07:32:46 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j6K6Wk6w015598; Wed, 20 Jul 2005 07:32:46 +0100 Received: from zurich.ibm.com (sig-9-145-255-17.de.ibm.com [9.145.255.17]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA50332; Wed, 20 Jul 2005 08:32:44 +0200 Message-ID: <42DDF00C.90807@zurich.ibm.com> Date: Wed, 20 Jul 2005 08:32:44 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Manfredi, Albert E" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Bob Hinden , global-v6@lists.apnic.net Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Manfredi, Albert E wrote: >>A /128 breaks IPv6 Privacy Addresses (RFC3041). Every device >>needs a /64 >>to allow this mechanism to be used. >> >>Bob > > > Alternative mechanisms could permit interface IDs to be shorter than 64 > bits, for example 48 bits or far fewer than that. Interface IDs only > need to be unique within a given subnet, and subnets with long prefixes > could be small enough to make the uniqueness requirement easy to > achieve. And also resolve the privacy concern in RFC 3041, by not > creating interface IDs that are likely to be globally unique? > > If we're quibbling about conserving address space by assigning 56 vs 48 > bit prefixes to individual sites, imagine how much more flexibility and > savings could be achieved by allowing shorter interface IDs. Without > imposing the restriction in RFC 3513 Section 4, and without increasing > privacy concerns. No? I think this greatly underestimates the practical impact of shortening the IID. In reality /64 is an architectural boundary, even if in theory it isn't. I don't believe that revisiting this is realistic. And I don't believe it is in the least necessary. (This point really concerns draft-narten-iana-rir-ipv6-considerations-00.txt, not the current 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 Wed Jul 20 03:26:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv8xt-0003VU-4b; Wed, 20 Jul 2005 03:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv8xq-0003VP-Ub for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 03:25:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11098 for ; Wed, 20 Jul 2005 03:25:57 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv9Rc-0003pk-Rp for ipv6@ietf.org; Wed, 20 Jul 2005 03:56:46 -0400 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1048:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AD2461521E; Wed, 20 Jul 2005 16:25:29 +0900 (JST) Date: Wed, 20 Jul 2005 16:25:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 15 Jul 2005 11:39:55 -0700, >>>>> Bob Hinden said: > This starts a two week IPv6 working group last call on advancing: > Title : IPv6 Node Information Queries > Author(s) : M. Crawford, B. Haberman > Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt > Pages : 14 > Date : 2005-7-14 > to Experimental. Please send substantive comments to the IPv6 mailing > list. Editorial comments can be sent to the authors. I've confirmed my previous comments were addressed in this version. I'm okay with submitting this draft. 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 Wed Jul 20 04:45:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvACX-0000dq-N5; Wed, 20 Jul 2005 04:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvACR-0000bj-U3 for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 04:45:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19949 for ; Wed, 20 Jul 2005 04:45:05 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvAgE-0008EY-HO for ipv6@ietf.org; Wed, 20 Jul 2005 05:15:56 -0400 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1048:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E4B1F15218; Wed, 20 Jul 2005 17:45:03 +0900 (JST) Date: Wed, 20 Jul 2005 17:45:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Pashby, Ronald W CTR NSWCDD-B35" In-Reply-To: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> References: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipv6@ietf.org Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Mon, 18 Jul 2005 14:13:54 -0500, >>>>> "Pashby, Ronald W CTR NSWCDD-B35" said: > In the second paragraph of section 5 it reads: > "Compute the MD5 hash [11] of the first label of the Subject Name -- > the portion beginning with the first one-octet length field and up > to, but excluding, any subsequent length field. Append the first 32 > bits of that 128-bit hash to the prefix FF02:0:0:0:0: 2::/96. The > resulting multicast address will be termed the "NI Group Address" > for the name. A node will support an "NI Group Address" for each > associated Subject Name." > This does not follow the intent of RFC3307. RFC3307 intended for > dynamically assigned multicast ids be forced into the range from > 0x80000000 - 0xFFFFFFFF, to avoid overlapping at the layer 2 with > globally assigned addresses. Take for instance that a name hashes to > 0x00000001 (there is nothing that would hinder this) then every host > would receive it at the layer 2 level and would have to be processed > at the IP level. Likewise, the same would occur for any other IANA > assigned addresses. Hmm...when I first heard this point off-list, I didn't see the need for it. But after re-reading RFC3307, I tend to agree with you. In the literal sense, the current specification of the name-lookups document does not break RFC3307, since the link-local multicast groups defined for name-lookups do not set the "T" bit. But, in my understanding of the real intent of the RFC, those group should be categorized as "Dynamic IPv6 Multicast Addresses" (so we may even want to set the "T" bit for those groups). The problem is, as you commented, that this change will break existing implementations. I'm not sure how serious it is: I use the name-lookup protocol almost everyday, but I've never used the name-to-address mapping function using the hashed multicast group. Thus, I, for one, don't mind if we change the group range at this stage as an end user. As an implementor, I actually don't mind either. The code change would be pretty trivial. Of course, compatibility issues generally require broader inputs. We'll have to hear from other users or implementors of existing implementations before making the decision. 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 Wed Jul 20 05:38:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvB23-00033k-4l; Wed, 20 Jul 2005 05:38:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvB20-00033D-Qs for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 05:38:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25961 for ; Wed, 20 Jul 2005 05:38:22 -0400 (EDT) Received: from yamaha-ctcnetlink14.yamaha.co.jp ([218.216.190.126] helo=aphrodite.comm.yamaha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvBVn-0003bj-II for ipv6@ietf.org; Wed, 20 Jul 2005 06:09:13 -0400 Received: from aphrodite.comm.yamaha.co.jp by aphrodite.comm.yamaha.co.jp via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 20 Jul 2005 18:38:22 +0900 Received: from localhost (selene [133.176.112.13]) by comm.yamaha.co.jp (8.12.11/8.9.3/CY01) with ESMTP id j6K9bu2Q075683 for ; Wed, 20 Jul 2005 18:37:56 +0900 (JST) (envelope-from hirose@comm.yamaha.co.jp) Date: Wed, 20 Jul 2005 18:37:54 +0900 (JST) Message-Id: <20050720.183754.22498937.hirose@comm.yamaha.co.jp> To: ipv6@ietf.org From: Ryota Hirose X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi IPv6 hackers, Recent GbE NICs or GbE switches support Jumbo Frames, but RFC2464 provides that the maximum MTU of an Ethernet is 1500. So we cannot use the Jumbo Frames for IPv6. 2. Maximum Transmission Unit The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement received on an Ethernet interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value, that MTU option may be logged to system management but must be otherwise ignored. For example, on FreeBSD 5.4R, to send a Jumbo Frames of IPv4, I just only set the link MTU with ifconfig command. To send a Jumbo Frames of IPv6, I had to hack a kernel code to not compare link MTU with ETHERMTU(1500). BTW, Jinmei san suggested that KAME, NetBSD and OpenBSD are already hacked as above and this behavior may be only FreeBSD problem. But, according to RFC2464, FreeBSD behavior is right, and other BSDs is wrong. I know that this Jumbo Frames of GbE violates a specification of IEEE 802.3. But it is deploied already, and is used for a high performance application like the file servers. Does anyone have a plan to change the rule of RFC2464? Ryota Hirose Yamaha Corporation -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 06:43:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvC2f-0002h6-Jf; Wed, 20 Jul 2005 06:43:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvC2d-0002h1-Jn for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 06:43:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02755 for ; Wed, 20 Jul 2005 06:43:04 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvCWM-0008Eh-VV for ipv6@ietf.org; Wed, 20 Jul 2005 07:13:56 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DvC2C-0007KJ-2c; Wed, 20 Jul 2005 11:42:40 +0100 Message-ID: <42DE2AE1.2090606@dial.pipex.com> Date: Wed, 20 Jul 2005 11:43:45 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp References: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: ipv6@ietf.org, "Pashby, Ronald W CTR NSWCDD-B35" Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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="===============0236221233==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0236221233== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit

JINMEI Tatuya / 神明達哉 wrote: 
On Mon, 18 Jul 2005 14:13:54 -0500, 
"Pashby, Ronald W CTR NSWCDD-B35" <ronald.pashby.ctr@navy.mil> said:
            

  
In the second paragraph of section 5 it reads:
"Compute the MD5 hash [11] of the first label of the Subject Name --
the portion beginning with the first one-octet length field and up
to, but excluding, any subsequent length field. Append the first 32
bits of that 128-bit hash to the prefix FF02:0:0:0:0: 2::/96. The
resulting multicast address will be termed the "NI Group Address"
for the name. A node will support an "NI Group Address" for each
associated Subject Name."
    

  
This does not follow the intent of RFC3307. RFC3307 intended for
dynamically assigned multicast ids be forced into the range from
0x80000000 - 0xFFFFFFFF, to avoid overlapping at the layer 2 with
globally assigned addresses. Take for instance that a name hashes to
0x00000001 (there is nothing that would hinder this) then every host
would receive it at the layer 2 level and would have to be processed
at the IP level. Likewise, the same would occur for any other IANA
assigned addresses. 
    

Hmm...when I first heard this point off-list, I didn't see the need
for it.  But after re-reading RFC3307, I tend to agree with you.  In
the literal sense, the current specification of the name-lookups
document does not break RFC3307, since the link-local multicast groups
defined for name-lookups do not set the "T" bit.  But, in my
understanding of the real intent of the RFC, those group should be
categorized as "Dynamic IPv6 Multicast Addresses" (so we may even want
to set the "T" bit for those groups).
As I said in my previous posting, I don't think you ought to think of either solicited node multicast groups or these groups as dynamically allocated.  The groups exist statically whether any nodes are using them or not.  The dynamically allocated ones are (IMO) those that an application needs to create with some guarantee of uniqueness in order to send on. No dynamic allocation is needed for the name lookup addresses.

It occurs to me that there is another issue related to one we have discussed for Neighbour Discovery: A node that implements the response side of name lookup has to join the relevant multicast groups that we are talking about and should send out the MLDv1 or MLDv2 listener messages to ensure that the multicast messages will reach it through any switches that happen to be in the way.  Do implementors do this anyway?

Two points as regards the possible clash of Layer 2 addresses:
- Taking a subset of the bits of an MD5 hash obviously increases the likelihood of a collision but the hashes will still be uniformly distributed over [0,2^32) - there is not a disproportionate chance of hitting (say) the all-nodes address.
- The probability of getting a clash between independently randomly allocated groups with 32 bit identifiers does not start to get significant (i.e. bigger than about 0.01) until you have several thousand addresses actually in use on a link (see Mark Handley's work).

>From a practical point of view, given the low rate of packets that would be expected from the name lookup protocol, is the impact of a low probability Layer 2 clash *really* going to make much of an impact on even a time sensitive application?  My understanding of the reason for trying to spread the ND and name lookup multicasts across a wide spectrum of groups is to reduce the number of low level interrupts resulting from acquisition of packets that prove not to be of interest to this node when their IP addresses are examined.  Whatever group a name lookup packet is on, if it is intended for a given node it has to be received and processed by that node.  Three things are going to help: Keeping packets that are of no interest off a switched connection to the node; if they do come past on the wire, ignoring them at the lowest possible level; and using Ethernet QoS for the time sensitive packets - otherwise all packets of interest (and disinterest) just get dumped into a single queue for IP processing.

Regards,
Elwyn
The problem is, as you commented, that this change will break existing
implementations.  I'm not sure how serious it is: I use the
name-lookup protocol almost everyday, but I've never used the
name-to-address mapping function using the hashed multicast group.
Thus, I, for one, don't mind if we change the group range at this
stage as an end user.  As an implementor, I actually don't mind
either.  The code change would be pretty trivial.

Of course, compatibility issues generally require broader inputs.
We'll have to hear from other users or implementors of existing
implementations before making the decision.

					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
--------------------------------------------------------------------
--===============0236221233== 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 -------------------------------------------------------------------- --===============0236221233==-- From ipv6-bounces@ietf.org Wed Jul 20 07:10:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCTF-0007bY-61; Wed, 20 Jul 2005 07:10:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCTD-0007bT-5C for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 07:10:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05047 for ; Wed, 20 Jul 2005 07:10:32 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvCx0-0001e4-VL for ipv6@ietf.org; Wed, 20 Jul 2005 07:41:24 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6KBAJIh030313; Wed, 20 Jul 2005 13:10:20 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6KBAJIb010651; Wed, 20 Jul 2005 13:10:19 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6KBAJom010650; Wed, 20 Jul 2005 13:10:19 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 20 Jul 2005 13:10:19 +0200 From: Stig Venaas To: Elwyn Davies Message-ID: <20050720111019.GB10519@storhaugen.uninett.no> References: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> <42DE2AE1.2090606@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42DE2AE1.2090606@dial.pipex.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipv6@ietf.org, "Pashby, Ronald W CTR NSWCDD-B35" , jinmei@isl.rdc.toshiba.co.jp Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Please don't send HTML, hard for me to read and quote. Clients should definitely do an MLD join for this group (just as they should for the solicited multicast address used for ND). My experience is also that clients do join both the "solicited" and the "name-lookup". I would be interested to hear of any implementations that don't. If not, the job for snooping switches will be pretty difficult. In general we need to make it very clear that one always needs to do MLD joins, except for ff02::1. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 07:24:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCh9-0006Me-Re; Wed, 20 Jul 2005 07:24:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCh8-0006MU-3p for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 07:24:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06292 for ; Wed, 20 Jul 2005 07:24:57 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvDAw-0002hs-5J for ipv6@ietf.org; Wed, 20 Jul 2005 07:55:47 -0400 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1048:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 37C801521A; Wed, 20 Jul 2005 20:24:54 +0900 (JST) Date: Wed, 20 Jul 2005 20:24:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Elwyn Davies In-Reply-To: <42DE2AE1.2090606@dial.pipex.com> References: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> <42DE2AE1.2090606@dial.pipex.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ipv6@ietf.org, "Pashby, Ronald W CTR NSWCDD-B35" Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 20 Jul 2005 11:43:45 +0100, >>>>> Elwyn Davies said: > As I said in my previous posting, I don't think you ought to think > of either solicited node multicast groups or these groups as > dynamically allocated. The groups exist statically whether any > nodes are using them or not. The dynamically allocated ones are > (IMO) those that an application needs to create with some guarantee > of uniqueness in order to send on. No dynamic allocation is needed > for the name lookup addresses. Whether it's really a 'dynamically allocated' address or not is just a matter of definition. I won't surprise if different people have different views on this. I just represented my own interpretation of the sense of RFC3307. Of course, I could be wrong, in which case the author of the RFC will hopefully correct me. In any case, I don't think the definition of 'dynamic' is a real issue. The issue is whether it makes sense to try avoiding layer-2 and layer-3 collisions for the multicast groups regarding the icmp-name-lookup protocol. In my understanding, a very rough summary of your argument against this point is "the probability of collisions should be very rare due to the use of MD5 hashing, so don't bother" (correct?). I see the point, and I can live with that. In my undersatnding, however, the trend of the IETF is to not rely on that type of arguments and is to try avoiding possible collisions more and more explicitly. In fact, we rejected the idea of "duplicate interface-ID detection' instead of 'duplicate address detection', based on the argument of "the probability of collisions should be rare since the IDs should be highly unique, so why not optimize?". Also, RFC3307 seems to try avoiding collisions even though it recommends the use of good random group IDs (according to the second paragraph of Section 4.3.2). So, it seems more consistent to me to avoid collisions in this case despite the use of reasonably distributed IDs. It's not a strong opinion though. If a majority prefers keeping the current range, I won't fight against that. 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 Wed Jul 20 07:33:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCpS-00010q-IR; Wed, 20 Jul 2005 07:33:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCpQ-000101-T5 for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 07:33:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06903 for ; Wed, 20 Jul 2005 07:33:31 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvDJG-0003JA-39 for ipv6@ietf.org; Wed, 20 Jul 2005 08:04:22 -0400 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1048:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 686801521A; Wed, 20 Jul 2005 20:33:30 +0900 (JST) Date: Wed, 20 Jul 2005 20:33:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Elwyn Davies In-Reply-To: <42DE2AE1.2090606@dial.pipex.com> References: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> <42DE2AE1.2090606@dial.pipex.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org, "Pashby, Ronald W CTR NSWCDD-B35" Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org (Forgot to mention this) >>>>> On Wed, 20 Jul 2005 11:43:45 +0100, >>>>> Elwyn Davies said: > It occurs to me that there is another issue related to one we have discussed > for Neighbour Discovery: A node that implements the response side of name > lookup has to join the relevant multicast groups that we are talking about and > should send out the MLDv1 or MLDv2 listener messages to ensure that the > multicast messages will reach it through any switches that happen to be in the > way. Do implementors do this anyway? I don't know how this is relevant to the particular point of the group range, but anyway, yes, our implementation do that. And, I don't see any reason why implementations don't do that: it seems pretty trivial point to me. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. (this is also forgotten in my previous response:-) it would be nice if you could send your message in a plain text instead of 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 Jul 20 08:07:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvDM1-0002zW-LY; Wed, 20 Jul 2005 08:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvBEU-00012M-31 for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 05:51:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27366 for ; Wed, 20 Jul 2005 05:51:15 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvBiH-0004Yo-Dy for ipv6@ietf.org; Wed, 20 Jul 2005 06:22:06 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DvBEH-0000WJ-Bc; Wed, 20 Jul 2005 02:51:05 -0700 Message-Id: <6.2.1.2.2.20050720112926.03f043d0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 20 Jul 2005 11:50:47 +0200 To: Brian E Carpenter , "Manfredi, Albert E" From: "JFC (Jefsey) Morfin" In-Reply-To: <42DDF00C.90807@zurich.ibm.com> References: <42DDF00C.90807@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Wed, 20 Jul 2005 08:07:12 -0400 Cc: ipv6@ietf.org, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At 08:32 20/07/2005, Brian E Carpenter wrote: >In reality /64 is an architectural boundary, even if in theory >it isn't. I don't believe that revisiting this is realistic. And I don't >believe it is in the least necessary. Dear Brian, i am afraid this is orthogonal: - "In reality /64 is an architectural boudary", means it is because of the practice, common thinking, etc. - "I don't believe that revisiting this is realistic", means such revisiting would come from a proposition. You cannot impeach a new practice. One of the rules of network design is "whatever is possible to try and is fun or brings money or worries to someone will be used". But you can certainly propose ways towards a better (network wise) support of such new practices. I suppose that you refer to /64 in what we could name the "legacy" environment (the way the Internet is today). Now think of a totally different approach of the Internet (we can actually support 6 full ones with the /3 blocs) where a user could get far less InterfaceIDs (and be happy with it) because for example the routing system and ganularity would be different, or hardware would change, or NGN, or MGN, or etc. Up to now, what has been investigated is what IPv6 can bring to the network. I think another interesting approach is to start from a universal numbering space and investigate what IPv6 could bring to it (with the current technology or not) and to all its constituents. May be the way to understand how to deploy IPv6 faster instead of selling it slowly? jfc -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 08:07:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvDM2-0002zx-IO; Wed, 20 Jul 2005 08:07:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvBi2-0000YA-4R for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 06:21:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01120 for ; Wed, 20 Jul 2005 06:21:46 -0400 (EDT) Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvCBo-00074g-Rv for ipv6@ietf.org; Wed, 20 Jul 2005 06:52:38 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.3/8.13.3/Mux) with ESMTP id j6KALQjB027730; Wed, 20 Jul 2005 12:21: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.12.10) with ESMTP id j6KAQY4H007244; Wed, 20 Jul 2005 12:26:34 +0200 Date: Wed, 20 Jul 2005 12:21:26 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: "JFC (Jefsey) Morfin" In-Reply-To: <6.2.1.2.2.20050720112926.03f043d0@mail.jefsey.com> Message-ID: References: <42DDF00C.90807@zurich.ibm.com> <6.2.1.2.2.20050720112926.03f043d0@mail.jefsey.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.36 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Wed, 20 Jul 2005 08:07:12 -0400 Cc: ipv6@ietf.org, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-DACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, 20 Jul 2005, JFC (Jefsey) Morfin wrote: > > Up to now, what has been investigated is what IPv6 can bring to the > network. I think another interesting approach is to start from a universal > numbering space and investigate what IPv6 could bring to it (with the > current technology or not) and to all its constituents. May be the way to > understand how to deploy IPv6 faster instead of selling it slowly? This is a completly different discussion and IPv6 is just one of many tools available. Problem is, are no use in trying to create lots of funky services if the communication wont work... and no one (almost) want to use time and money on getting the communication to work without a service using it. -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 08:07:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvDM4-00031D-1a; Wed, 20 Jul 2005 08:07:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvBnR-0002cf-TN for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 06:27:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01503 for ; Wed, 20 Jul 2005 06:27:23 -0400 (EDT) Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvCHE-0007Sj-Cv for ipv6@ietf.org; Wed, 20 Jul 2005 06:58:14 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.3/8.13.3/Mux) with ESMTP id j6KARLGL010343; Wed, 20 Jul 2005 12:27:21 +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.12.10) with ESMTP id j6KAWT9L007798; Wed, 20 Jul 2005 12:32:29 +0200 Date: Wed, 20 Jul 2005 12:27:21 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: "JFC (Jefsey) Morfin" In-Reply-To: <6.2.1.2.2.20050720112926.03f043d0@mail.jefsey.com> Message-ID: References: <42DDF00C.90807@zurich.ibm.com> <6.2.1.2.2.20050720112926.03f043d0@mail.jefsey.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.36 X-Spam-Score: 1.0 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Wed, 20 Jul 2005 08:07:12 -0400 Cc: ipv6@ietf.org, roger@jorgensen.no, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-DACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, 20 Jul 2005, JFC (Jefsey) Morfin wrote: > > Up to now, what has been investigated is what IPv6 can bring to the > network. I think another interesting approach is to start from a universal > numbering space and investigate what IPv6 could bring to it (with the > current technology or not) and to all its constituents. May be the way to > understand how to deploy IPv6 faster instead of selling it slowly? This is a completly different discussion and IPv6 is just one of many tools available. Problem is, are no use in trying to create lots of funky services if the communication wont work... and no one (almost) want to use time and money on getting the communication to work without a service using it. -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 10:08:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFFm-0000Mm-9q; Wed, 20 Jul 2005 10:08:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFFk-0000JA-IL for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 10:08:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18156 for ; Wed, 20 Jul 2005 10:08:50 -0400 (EDT) Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvFjX-0004kI-RX for ipv6@ietf.org; Wed, 20 Jul 2005 10:39:43 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DvFFT-0007VJ-Se; Wed, 20 Jul 2005 15:08:36 +0100 Message-ID: <42DE5B25.9060902@dial.pipex.com> Date: Wed, 20 Jul 2005 15:09:41 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas References: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> <42DE2AE1.2090606@dial.pipex.com> <20050720111019.GB10519@storhaugen.uninett.no> In-Reply-To: <20050720111019.GB10519@storhaugen.uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, "Pashby, Ronald W CTR NSWCDD-B35" , jinmei@isl.rdc.toshiba.co.jp Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Stig Venaas wrote: >Please don't send HTML, hard for me to read and quote. > >Clients should definitely do an MLD join for this group (just as they >should for the solicited multicast address used for ND). My experience >is also that clients do join both the "solicited" and the "name-lookup". >I would be interested to hear of any implementations that don't. If not, >the job for snooping switches will be pretty difficult. In general we >need to make it very clear that one always needs to do MLD joins, except >for ff02::1. > >Stig > > Agreed. We just need a few words as per 2461bis. Something like.. Nodes intending to respond to name lookup queries MUST join the appropriate multicast addresses for the names to wghich they will respond. Joining the name lookup multicast address SHOULD be done using the Multicast Listener Discovery [MLD] or [MLDv2] protocols. Elwyn -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 11:28:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvGUw-0006Rq-Q7; Wed, 20 Jul 2005 11:28:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvGUv-0006Nc-6A for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 11:28:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01230 for ; Wed, 20 Jul 2005 11:28:34 -0400 (EDT) Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvGyh-0003ab-9K for ipv6@ietf.org; Wed, 20 Jul 2005 11:59:28 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DvGUb-0004D6-BK; Wed, 20 Jul 2005 16:28:17 +0100 Message-ID: <42DE6DD2.4070006@dial.pipex.com> Date: Wed, 20 Jul 2005 16:29:22 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp References: <041052AD735329479241C23E0813EB7E9EC872@NAEAMILLEX05VA.nadsusea.nads.navy.mil> <42DE2AE1.2090606@dial.pipex.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA01230 Cc: ipv6@ietf.org, "Pashby, Ronald W CTR NSWCDD-B35" Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>>>>>On Wed, 20 Jul 2005 11:43:45 +0100,=20 >>>>>>Elwyn Davies said: >>>>>> =20 >>>>>> > > =20 > >>As I said in my previous posting, I don't think you ought to think >>of either solicited node multicast groups or these groups as >>dynamically allocated. The groups exist statically whether any >>nodes are using them or not. The dynamically allocated ones are >>(IMO) those that an application needs to create with some guarantee >>of uniqueness in order to send on. No dynamic allocation is needed >>for the name lookup addresses. >> =20 >> > >Whether it's really a 'dynamically allocated' address or not is just a >matter of definition. I won't surprise if different people have >different views on this. I just represented my own interpretation of >the sense of RFC3307. Of course, I could be wrong, in which case the >author of the RFC will hopefully correct me. > =20 > Indeed RFC3307 has to some extent been overtaken by events and the exact=20 meaning is now unclear. As you say it doesn't really matter for the=20 purposes of this discussion. >In any case, I don't think the definition of 'dynamic' is a real >issue. The issue is whether it makes sense to try avoiding layer-2 >and layer-3 collisions for the multicast groups regarding the >icmp-name-lookup protocol. > =20 > >In my understanding, a very rough summary of your argument against >this point is "the probability of collisions should be very rare due >to the use of MD5 hashing, so don't bother" (correct?). I see the >point, and I can live with that. > >In my undersatnding, however, the trend of the IETF is to not rely on >that type of arguments and is to try avoiding possible collisions more >and more explicitly. In fact, we rejected the idea of "duplicate >interface-ID detection' instead of 'duplicate address detection', >based on the argument of "the probability of collisions should be rare >since the IDs should be highly unique, so why not optimize?". Also, >RFC3307 seems to try avoiding collisions even though it recommends the >use of good random group IDs (according to the second paragraph of >Section 4.3.2). So, it seems more consistent to me to avoid >collisions in this case despite the use of reasonably distributed IDs. > > =20 > The real point I was trying to get across is that Layer 2 multicast=20 address collisions are essentially unavoidable, but that they are, at=20 least in the name lookup case, benign, especially as far as performance=20 is concerned. So I wouldn't change the algorithm. I agreed with the DAD decision, and making sure the layer 3 addresses=20 are unique for a given purpose is clearly the right answer, because a=20 collision could have disastrous effects unless nodes/applications are=20 expecting it. The name lookup and ND solicited node Layer 3 addresses are taken from=20 different spaces from any of the RFC3307 addresses so there can never be=20 a collision between these different types of addresses at Layer 3. The name lookup (and ND) solution reduces the probability of multiple=20 nodes using the same Layer 3 and Layer 2 addresses for this purpose but=20 ensure that a collision doesn't matter, although there will be a small=20 amount of wasted effort on nodes with Layer 3 collisions. As far as I can see, there is bound to be a small residual probability=20 of a Layer 2 multicast address collision on account of there being many=20 less Layer 2 multicast addresses than Layer 3 multicast addresses. In=20 the vast majority of cases this will not matter because nodes will=20 receive and process just the packets they would have received anyway.=20 There will be a small number of (relatively) pathological cases where a=20 packet goes to a number of listeners that aren't interested. However,=20 especially in the case of name lookup, the number of packets involved at=20 any one node is likely to be very small. Regards, Elwyn >It's not a strong opinion though. If a majority prefers keeping the >current range, I won't fight against that. > > 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 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 11:34:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvGay-0002vd-AU; Wed, 20 Jul 2005 11:34:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvGaw-0002vS-8Z for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 11:34:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02108 for ; Wed, 20 Jul 2005 11:34:47 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvH4l-00048q-Bx for ipv6@ietf.org; Wed, 20 Jul 2005 12:05:41 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA10690; Wed, 20 Jul 2005 08:34:31 -0700 (PDT) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6KFYUs11614; Wed, 20 Jul 2005 08:34:30 -0700 (PDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 20 Jul 2005 11:34:29 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2005 11:34:29 -0400 Message-ID: Thread-Topic: [GLOBAL-V6] Re:I-DACTION:draft-narten-ipv6-3177bis-48boundary-00.txt Thread-Index: AcWNJJdOtz+1DPqpRqCtE8mj6y+JkgAFu9eA From: "Manfredi, Albert E" To: "Roger Jorgensen" X-OriginalArrivalTime: 20 Jul 2005 15:34:29.0708 (UTC) FILETIME=[84E6F8C0:01C58D40] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, global-v6@lists.apnic.net Subject: RE: [GLOBAL-V6] Re:I-DACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Not necessarily lots of funky services. Here's the sequence that leads to this interface ID length question. 1. RFC 2373, the precursor of RFC 3513, introduces 64-bit IIDs. Okay, seems logical. (Also reminiscent of NSAPA structure from back in ION wg days.) 2. RFC 3513 strengthens that, suggesting that the IANA assign only globally unique addresses starting in binary 001, which means by extension that these will only have 64-bit IIDs. Okay, fair enough. 3. RFC 3177 suggests that every site be assigned a /48 prefix at least. 4. I-D 3177-bis introduces the idea that wanton waste is perhaps not a good idea, and /56 prefixes would be a better idea than default /48 prefixes. 5. RFC 3041 says maybe those globally unique IIDs create a problem anyway. I come to some conclusions from this. First, if 64-bit IIDs create security problems, then one possible remedy is not to insist that all IANA assignments must use 64-bit IIDs. Second, that if all IANA assignments do not have to consist of 64-bit IIDs, the concerns of I-D 3177-bis are also alleviated. Third, that the underlying model on which RFCs 3513 and 3177 are based seems to be heavily biased to assignment of IP addresses from ISPs to businesses and residences, client-server architectures, and address autoconfiguration. But perhaps that's not going to be where the future leads, for the vast majority of IPv6 devices and applications. Perhaps we're looking at bewildering arrays of devices (sensors and actuators) embedded in all manner of sites, including mobile platforms, roadways, in individual home systems, where globally unique IIDs are not appropriate and where very large numbers of relatively small IP subnets are instead the norm. So yes, this is a different discussion perhaps, but not unrelated. It says, why are we following just this one path? Bert > -----Original Message----- > From: Roger Jorgensen [mailto:rogerj@jorgensen.no]=20 > Sent: Wednesday, July 20, 2005 5:27 AM > To: JFC (Jefsey) Morfin > Cc: ipv6@ietf.org; roger@jorgensen.no; global-v6@lists.apnic.net > Subject: Re: [GLOBAL-V6]=20 > Re:I-DACTION:draft-narten-ipv6-3177bis-48boundary-00.txt >=20 > On Wed, 20 Jul 2005, JFC (Jefsey) Morfin wrote: > >=20 > > Up to now, what has been investigated is what IPv6 can bring to the=20 > > network. I think another interesting approach is to start=20 > from a universal=20 > > numbering space and investigate what IPv6 could bring to it=20 > (with the=20 > > current technology or not) and to all its constituents. May=20 > be the way to=20 > > understand how to deploy IPv6 faster instead of selling it slowly? >=20 > This is a completly different discussion and IPv6 is just one of many > tools available. Problem is, are no use in trying to create=20 > lots of funky > services if the communication wont work... and no one=20 > (almost) want to=20 > use time and money on getting the communication to work=20 > without a service=20 > using it.=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 Jul 20 15:16:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvK3T-00068F-Bg; Wed, 20 Jul 2005 15:16:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvEUn-00089z-Ea for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 09:20:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13960 for ; Wed, 20 Jul 2005 09:20:19 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvEyc-0001WM-Lk for ipv6@ietf.org; Wed, 20 Jul 2005 09:51:11 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DvEUj-0005ZR-Qm; Wed, 20 Jul 2005 06:20:18 -0700 Message-Id: <6.2.1.2.2.20050720150709.04dd5cf0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 20 Jul 2005 15:19:58 +0200 To: Roger Jorgensen From: "JFC (Jefsey) Morfin" In-Reply-To: References: <42DDF00C.90807@zurich.ibm.com> <6.2.1.2.2.20050720112926.03f043d0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Wed, 20 Jul 2005 15:16:29 -0400 Cc: ipv6@ietf.org, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re: I-DACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At 12:21 20/07/2005, Roger Jorgensen wrote: >On Wed, 20 Jul 2005, JFC (Jefsey) Morfin wrote: > > > > > Up to now, what has been investigated is what IPv6 can bring to the > > network. I think another interesting approach is to start from a universal > > numbering space and investigate what IPv6 could bring to it (with the > > current technology or not) and to all its constituents. May be the way to > > understand how to deploy IPv6 faster instead of selling it slowly? > >This is a completly different discussion and IPv6 is just one of many >tools available. Problem is, are no use in trying to create lots of funky >services if the communication wont work... and no one (almost) want to >use time and money on getting the communication to work without a service >using it. I am not sure I understand your comment. I am talking of IPv6 support of the universal numbering space, not of other tools. Problem IMHO is to understand where regidity is useful and where it impeaches solutions people would need to put your time and money into? I am always against exclusive and exclusion, whatever their good reasons, when this is possible. All the more in techniics and innovation. Just says that. I see advantages in having /48 /56 /64 etc. thresholds in rates. Not really in technics. But I certainly see the technical con/pros why to use these threeshold, the same I see advantages in /128 and in InterfaceID Grids. Or did I misread your comment? Thank you. jfc -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 15:16:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvK3U-00068g-8m; Wed, 20 Jul 2005 15:16:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvIqD-0000BR-BL for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 13:58:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16038 for ; Wed, 20 Jul 2005 13:58:44 -0400 (EDT) Received: from pony1pub.arc.nasa.gov ([128.102.31.41] helo=arc.nasa.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvJK2-0006Ft-Oz for ipv6@ietf.org; Wed, 20 Jul 2005 14:29:38 -0400 Received: from [129.99.139.64] ([129.99.139.64] verified) by pony1pub.arc.nasa.gov (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 20313534 for ipv6@ietf.org; Wed, 20 Jul 2005 10:58:28 -0700 Message-ID: <42DE90BC.3050403@nasa.gov> Date: Wed, 20 Jul 2005 10:58:20 -0700 From: Hugh LaMaster User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org References: <20050720.183754.22498937.hirose@comm.yamaha.co.jp> In-Reply-To: <20050720.183754.22498937.hirose@comm.yamaha.co.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Jul 2005 15:16:29 -0400 Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hugh LaMaster List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Ryota Hirose wrote: > Hi IPv6 hackers, > > Recent GbE NICs or GbE switches support Jumbo Frames, but RFC2464 > provides that the maximum MTU of an Ethernet is 1500. So we cannot > use the Jumbo Frames for IPv6. As I read it, RFC2464 says that the maximum *default* MTU is 1500, and, anything larger than that must be manually configured. It doesn't say that it is prohibited. > 2. Maximum Transmission Unit > > The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500 > octets. This size may be reduced by a Router Advertisement [DISC] > containing an MTU option which specifies a smaller MTU, or by manual > configuration of each node. If a Router Advertisement received on an > Ethernet interface has an MTU option specifying an MTU larger than > 1500, or larger than a manually configured value, that MTU option may > be logged to system management but must be otherwise ignored. > > For example, on FreeBSD 5.4R, to send a Jumbo Frames of IPv4, I just > only set the link MTU with ifconfig command. To send a Jumbo Frames > of IPv6, I had to hack a kernel code to not compare link MTU with > ETHERMTU(1500). > > BTW, Jinmei san suggested that KAME, NetBSD and OpenBSD are already > hacked as above and this behavior may be only FreeBSD problem. > But, according to RFC2464, FreeBSD behavior is right, and other > BSDs is wrong. I haven't tried this myself on FreeBSD 5.4R, but, if so, it is a bug, because manual configuration of MTU larger than 1500 is not prohibited by RFC2464. Thanks for pointing the FreeBSD bug out. Please report it to the FreeBSD mailing lists (-current, -net). > I know that this Jumbo Frames of GbE violates a specification of IEEE > 802.3. But it is deploied already, and is used for a high performance > application like the file servers. Does anyone have a plan to change > the rule of RFC2464? Jumbo frames are essential, and, do not violate RFC2464. Unfortunately, they are effectively deprecated by requiring manual configuration of each node, since RFC2464 effectively disallows configuration of jumbo frames through router advertisements. Probably OK, though, since most jumbo frame subnets today are manually configured anyway. However, the RFC should not discourage jumbo frames. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 16:08:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKrv-0006K6-RD; Wed, 20 Jul 2005 16:08:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKrr-0006J6-Tm for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 16:08:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01349 for ; Wed, 20 Jul 2005 16:08:33 -0400 (EDT) Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvLLk-000790-Kk for ipv6@ietf.org; Wed, 20 Jul 2005 16:39:29 -0400 Received: from taynzmail03.nz-tay.cpqcorp.net (relay.wipro.tcpn.com [16.47.4.103]) by atlrel7.hp.com (Postfix) with ESMTP id B9AC116C8; Wed, 20 Jul 2005 16:08:32 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 736E120C6; Wed, 20 Jul 2005 16:08:32 -0400 (EDT) Received: from [16.116.104.135] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j6KK8Vd0001204764; Wed, 20 Jul 2005 16:08:31 -0400 (EDT) Message-ID: <42DEAF3F.6080001@hp.com> Date: Wed, 20 Jul 2005 16:08:31 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti , erik.nordmark@sun.com, julien.laganier@sun.com 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: b84f8c8fba0e1389e5eb998b64078964 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 Socket API for source address selection > Author(s) : E. Nordmark, et al. > Filename : draft-chakrabarti-ipv6-addrselect-api-03.txt Hi Samita, Erik, and Julien, Didn't see this sent to the IPv6 ML, but sending comments here, most are editorial. -Brian ------------------------------------------------------------------------ Overall comment: 1. The draft talks about setting flag X and flag not-X, but the only place I see where this can happen is trying to set these together: IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA AI_PREFER_SRC_CGA | AI_PREFER_SRC_NONCGA Am I missing something? Can I somehow turn-off the use of Care-of Addresses as source addresses? Maybe it's implied that if I don't set the flag in the setsockopt()/getaddrinfo() call that it turns-off using that type of source address? ------------------------------------------------------------------------ Section 4: . Not in6.h? ------------------------------------------------------------------------ Section 5: First paragraph: Another strategy is to call down to network layer to retrieve source /network/the network/ ------------------------------------------------------------------------ Section 6: The example code differs from that in Section 5, plus has a few typos. I'll try and do this in diff -/+ style: - uint32_t flags; - - flags = IPV6_PREFER_SRC_TMP; --- + uint32_t flags = IPV6_PREFER_SRC_TMP; if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, (char *) &flags, sizeof (flags)) == -1) { perror("setsockopt IPV6_ADDR_REFERENCES"); } An application which needs to be able to restore the default settings on the socket would instead do this: uint32_t save_flags, flags; int optlen = sizeof (save_flags); - /* Save the existing IPv6_ADDR_PREFERENCE FLAG now */ --- + /* Save the existing IPv6_ADDR_PREFERENCES flags now */ if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, &save_flags, &optlen) == -1 { perror("getsockopt IPV6_ADDR_REFERENCES"); } /* Set the new flags */ flags = IPV6_PREFER_SRC_TMP; if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, (char *) &flags, sizeof (flags)) == -1) { perror("setsockopt IPV6_ADDR_REFERENCES"); } /* Do some work with the socket */ - ; / Restore the flags */ - flags = IPV6_PREFER_SRC_TMP; if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, (char *) &save_flags, sizeof (save_flags)) == -1) { perror("setsockopt IPV6_ADDR_REFERENCES"); } ------------------------------------------------------------------------ Application must not set conflicting flags; the only conflicts that /Application/Applications/ are checked for are flag X and flag not-X being set at the same time. Example of conflicting flags: IPV6_PREFER_SRC_TMP | IPV6_PREFER_SRC_PUBLIC. Maybe put "IP.. | IP.." on new line? Not that important. In order to allow different implementations to do different parts of address selection in getaddrinfo() and in the protocol stack, this specification requires that applications set the same flags when calling getaddrinfo() and when calling setsockopt(). For example, if the application sets IPV6_PREFER_SRC_COA flag, it must use /sets/sets the/ AI_PREFER_SRC_COA flag when calling getaddrinfo(). If applications /AI_PREFER_SRC_COA/the AI_PREFER_SRC_COA/ are not setting the same flags the behavior of the implementation is undefined. ------------------------------------------------------------------------ It is envisioned that Mobile IPv6 applications may want to choose Care-of-Address as source for short transaction (for efficiency) while roaming, but still keep Home address as source address for long lived communication for address stability. Thus it is recommended that applications take this idea into consideration and use the source address selection API for home-address and care-of -address selection appropriately. Similarly, an application may choose to set IPV6_PREFER_SRC_COA flag for datagram services; it uses home-address as source when at home and uses care-of-address outside home-network for short datagram transactions. This is an advantage of having flexibility of "preference" vs. "requirement". /my rewrite below/ It is envisioned that Mobile IPv6-aware applications may want to choose a Care-of Address as the source address for short transactions (for efficiency) while roaming, but still use the Home Address as the source address for long-lived communications for address stability. It is recommended that applications take this into consideration and use the source address selection API for Home Address and Care-of Address selection appropriately. I don't think you need those last two sentences since one is just repeating previous text anyways. ------------------------------------------------------------------------ Section 7: o If an implementation supports both stream and datagram sockets, it should implement the address preference mechanism API described in this document on types of sockets. /types/both types/ o Implementation supporting this API must implement both AI flags and socket option flags processing for portability of applications. /Implementation/An implementation/ ------------------------------------------------------------------------ Section 8: I think the flags need to be indented like this for readability: Source address selection rule #4 (prefer home address): IPV6_PREFER_SRC_HOME (default) ------------------------------------------------------------------------ Section 9: IPv4-mapped IPv6 addresses, which are IPv4 addresses in a form that can be used on an AF_INET6 socket, are supported in this API. In some cases the IPv4-mapped addresses may not make much sense because the attributes are IPv6 specific. For example, IPv6 temporary addresses are not the same as private IPv4 addresses. However, the IPv4 mapped-address support may be useful for mobile home address and care-of-address. At this point it is not understood whether this API has any value to IPv4 addresses or AF_INET family of sockets. The second to last sentence here is confusing (regarding mobile), can you explain what you meant? ------------------------------------------------------------------------ Section 10: Sometimes an application may have a requirement to only use address /address/an address/ ------------------------------------------------------------------------ The verification of temporary vs. public, home vs. care-of, CGA vs. not, are performed by a new function defined for this purpose: #include Not in6.h? boolean_t inet6_is_srcaddr(struct sockaddr_in6 *srcaddr, uint32_t flags); Where the flags contain the specified source preference flags. The function expects a non-NULL input for srcaddr. sockaddr_in6 structure must contain AF_INET6 as sin6_family. It also must contain the scope_id information if the source address is a link-local address. The function returns true when srcaddr corresponds to a valid address in the node and that address type satisfies the preference flag(s). If srcaddr input value does not correspond to any address in the node or it does not match an address which satisfy the preferences indicated, the function returns false. I think these two paragraphs should be re-written: The function expects a non-NULL input for srcaddr, where the sockaddr_in6 structure is initialized as follows: sin6_addr is the 128-bit IPv6 address sin6_family must be set to AF_INET6 sin6_scope_id must be set if the address is link-local The flags argument contains the specified source preference flags. The function returns true (1) when the IPv6 address corresponds to a valid address in the node and satisfies the given preference flags. If the IPv6 address input value does not correspond to any address in the node, or it does not match an address which satisfies the preference flags indicated, the function returns false (0). ------------------------------------------------------------------------ This function can handle multiple valid flags combination as its /flags combination/preference flag combinations/ second parameter, for example IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_TMP, which means that all flags must be satisfied for the result to be true. Invalid flag values result in false return value. /false/a false/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 17:10:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvLpf-0006ol-VY; Wed, 20 Jul 2005 17:10:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvLpd-0006oU-O0 for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 17:10:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26475 for ; Wed, 20 Jul 2005 17:10:19 -0400 (EDT) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvMJW-0001Db-Ot for ipv6@ietf.org; Wed, 20 Jul 2005 17:41:16 -0400 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 20 Jul 2005 21:10:19 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 20 Jul 2005 21:10:06 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Jul 2005 16:09:48 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9EC874@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt Thread-Index: AcWNP7L9W0QU3nMeRheB8vd3mnN9MQALZ08A From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Elwyn Davies" , X-OriginalArrivalTime: 20 Jul 2005 21:09:48.0875 (UTC) FILETIME=[5CDC39B0:01C58D6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ipv6@ietf.org Subject: RE: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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="===============0581367205==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0581367205== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBkaXNhZ3JlZSB0aGF0IGxheWVyMiBjb2xsaXNpb25zIGFyZSB1bmF2b2lkYWJsZS4gSWYgeW91 IGZvbGxvdyBSRkMzMzA3IHRoZW4gY29sbGlzaW9ucyBiZXR3ZWVuIGR5bmFtaWNhbGx5IGFzc2ln bmVkIGFuZCBwZXJtYW5lbnQgYXNzaWduZWQgYWRkcmVzc2VzIGFyZSB0b3RhbGx5IGF2b2lkYWJs ZSAobGlrZSB0aGV5IGFyZSBpbnRlbmRlZCkuIFRoZSBpc3N1ZSBoZXJlIGlzIHRoYXQgdGhpcyBk cmFmdCBkb2VzIG5vdCBmb2xsb3cgdGhlIGludGVudCBvZiAzMzA3Lg0KDQpBcyBmYXIgYXMgYmVu aWduIGdvZXMsIGV2ZXJ5b25lIGNvbnNpZGVycyB0aGUgZWZmZWN0IG9mIHNlbmRpbmcgIk5hbWUg UXVlcmllcyIgYW5kIGJlY2F1c2Ugb2YgYSBjb2xsaXNpb24gYSBob3N0IHRoYXQgam9pbmVkICJh bm90aGVyIiBncm91cCBnZXRzIHRob3NlIHF1ZXJpZXMuIEJ1dCB0aGUgb3Bwb3NpdGUgY2FzZSBp cyB0aGUgbWFqb3Igb25lLiBUYWtlIGZvciBpbnN0YW5jZSB0aGF0IGEgbXVsdGljYXN0IGdyb3Vw IGlzIGJlaW5nIHVzZWQgdG8gc2VuZCBsYXJnZSBhbW91bnRzIG9mIHBhY2tldHMgcGVyIHNlY29u ZC4gQW5vdGhlciBob3N0IGlzIHJ1bm5pbmcgYSByZWFsLXRpbWUgbWlzc2lvbiBjcml0aWNhbCBh cHBsaWNhdGlvbiB0aGF0IGl0IG5vdCBkZXNpZ25lZCB0byByZWNlaXZlIGEgbGFyZ2UgbnVtYmVy IG9mIHBhY2tldHMgcGVyIHNlY29uZC4gIFRoZSBzZWNvbmQgaG9zdCBqdXN0IGhhcHBlbnMgdG8g am9pbiB0aGUgc2FtZSAobGF5ZXIgMikgZ3JvdXAgYmVjYXVzZSBvZiB0aGUgTUQ1IGhhc2ggb24g aXRzIG5hbWUuIFRoZW4gdGhlIGhvc3Qgd2lsbCBiZSBmbG9vZGVkIHdpdGggbXVsdGljYXN0IHRy YWZmaWMgYW5kIG1heSBjYXVzZSBpdCB0byBmYWlsIHRvIHBlcmZvcm0gaXRzIHJlYWwtdGltZSB0 YXNrLg0KDQpUaGUgc29sdXRpb24gaXMgdG8gaW5zdXJlIHRoYXQgY2VydGFpbiByYW5nZXMgb2Yg YWRkcmVzcyBjYW4gYmUgdXNlZCB0byBndWFyYW50ZWUgdGhhdCBjb2xsaXNpb24gd2lsbCBub3Qg aGFwcGVuLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRWx3eW4gRGF2aWVz IFttYWlsdG86ZWx3eW5kQGRpYWwucGlwZXguY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIw LCAyMDA1IDExOjI5DQpUbzogamlubWVpQGlzbC5yZGMudG9zaGliYS5jby5qcA0KQ2M6IEVsd3lu IERhdmllczsgaXB2NkBpZXRmLm9yZzsgUGFzaGJ5LCBSb25hbGQgVyBDVFIgTlNXQ0RELUIzNQ0K U3ViamVjdDogUmU6IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtaXBuZ3dnLWljbXAtbmFtZS1sb29r dXBzLTEyLnR4dA0KDQoNCg0KDQpKSU5NRUkgVGF0dXlhIC8g56We5piO6YGU5ZOJIHdyb3RlOg0K DQo+Pj4+Pj5PbiBXZWQsIDIwIEp1bCAyMDA1IDExOjQzOjQ1ICswMTAwLCANCj4+Pj4+PkVsd3lu IERhdmllcyA8ZWx3eW5kQGRpYWwucGlwZXguY29tPiBzYWlkOg0KPj4+Pj4+ICAgICAgICAgICAg DQo+Pj4+Pj4NCj4NCj4gIA0KPg0KPj5BcyBJIHNhaWQgaW4gbXkgcHJldmlvdXMgcG9zdGluZywg SSBkb24ndCB0aGluayB5b3Ugb3VnaHQgdG8gdGhpbmsNCj4+b2YgZWl0aGVyIHNvbGljaXRlZCBu b2RlIG11bHRpY2FzdCBncm91cHMgb3IgdGhlc2UgZ3JvdXBzIGFzDQo+PmR5bmFtaWNhbGx5IGFs bG9jYXRlZC4gIFRoZSBncm91cHMgZXhpc3Qgc3RhdGljYWxseSB3aGV0aGVyIGFueQ0KPj5ub2Rl cyBhcmUgdXNpbmcgdGhlbSBvciBub3QuICBUaGUgZHluYW1pY2FsbHkgYWxsb2NhdGVkIG9uZXMg YXJlDQo+PihJTU8pIHRob3NlIHRoYXQgYW4gYXBwbGljYXRpb24gbmVlZHMgdG8gY3JlYXRlIHdp dGggc29tZSBndWFyYW50ZWUNCj4+b2YgdW5pcXVlbmVzcyBpbiBvcmRlciB0byBzZW5kIG9uLiBO byBkeW5hbWljIGFsbG9jYXRpb24gaXMgbmVlZGVkDQo+PmZvciB0aGUgbmFtZSBsb29rdXAgYWRk cmVzc2VzLg0KPj4gICAgDQo+Pg0KPg0KPldoZXRoZXIgaXQncyByZWFsbHkgYSAnZHluYW1pY2Fs bHkgYWxsb2NhdGVkJyBhZGRyZXNzIG9yIG5vdCBpcyBqdXN0IGENCj5tYXR0ZXIgb2YgZGVmaW5p dGlvbi4gIEkgd29uJ3Qgc3VycHJpc2UgaWYgZGlmZmVyZW50IHBlb3BsZSBoYXZlDQo+ZGlmZmVy ZW50IHZpZXdzIG9uIHRoaXMuICBJIGp1c3QgcmVwcmVzZW50ZWQgbXkgb3duIGludGVycHJldGF0 aW9uIG9mDQo+dGhlIHNlbnNlIG9mIFJGQzMzMDcuICBPZiBjb3Vyc2UsIEkgY291bGQgYmUgd3Jv bmcsIGluIHdoaWNoIGNhc2UgdGhlDQo+YXV0aG9yIG9mIHRoZSBSRkMgd2lsbCBob3BlZnVsbHkg Y29ycmVjdCBtZS4NCj4gIA0KPg0KSW5kZWVkIFJGQzMzMDcgaGFzIHRvIHNvbWUgZXh0ZW50IGJl ZW4gb3ZlcnRha2VuIGJ5IGV2ZW50cyBhbmQgdGhlIGV4YWN0IA0KbWVhbmluZyBpcyBub3cgdW5j bGVhci4gQXMgeW91IHNheSBpdCBkb2Vzbid0IHJlYWxseSBtYXR0ZXIgZm9yIHRoZSANCnB1cnBv c2VzIG9mIHRoaXMgZGlzY3Vzc2lvbi4NCg0KPkluIGFueSBjYXNlLCBJIGRvbid0IHRoaW5rIHRo ZSBkZWZpbml0aW9uIG9mICdkeW5hbWljJyBpcyBhIHJlYWwNCj5pc3N1ZS4gIFRoZSBpc3N1ZSBp cyB3aGV0aGVyIGl0IG1ha2VzIHNlbnNlIHRvIHRyeSBhdm9pZGluZyBsYXllci0yDQo+YW5kIGxh eWVyLTMgY29sbGlzaW9ucyBmb3IgdGhlIG11bHRpY2FzdCBncm91cHMgcmVnYXJkaW5nIHRoZQ0K PmljbXAtbmFtZS1sb29rdXAgcHJvdG9jb2wuDQo+ICANCj4NCg0KPkluIG15IHVuZGVyc3RhbmRp bmcsIGEgdmVyeSByb3VnaCBzdW1tYXJ5IG9mIHlvdXIgYXJndW1lbnQgYWdhaW5zdA0KPnRoaXMg cG9pbnQgaXMgInRoZSBwcm9iYWJpbGl0eSBvZiBjb2xsaXNpb25zIHNob3VsZCBiZSB2ZXJ5IHJh cmUgZHVlDQo+dG8gdGhlIHVzZSBvZiBNRDUgaGFzaGluZywgc28gZG9uJ3QgYm90aGVyIiAoY29y cmVjdD8pLiAgSSBzZWUgdGhlDQo+cG9pbnQsIGFuZCBJIGNhbiBsaXZlIHdpdGggdGhhdC4NCj4N Cj5JbiBteSB1bmRlcnNhdG5kaW5nLCBob3dldmVyLCB0aGUgdHJlbmQgb2YgdGhlIElFVEYgaXMg dG8gbm90IHJlbHkgb24NCj50aGF0IHR5cGUgb2YgYXJndW1lbnRzIGFuZCBpcyB0byB0cnkgYXZv aWRpbmcgcG9zc2libGUgY29sbGlzaW9ucyBtb3JlDQo+YW5kIG1vcmUgZXhwbGljaXRseS4gIElu IGZhY3QsIHdlIHJlamVjdGVkIHRoZSBpZGVhIG9mICJkdXBsaWNhdGUNCj5pbnRlcmZhY2UtSUQg ZGV0ZWN0aW9uJyBpbnN0ZWFkIG9mICdkdXBsaWNhdGUgYWRkcmVzcyBkZXRlY3Rpb24nLA0KPmJh c2VkIG9uIHRoZSBhcmd1bWVudCBvZiAidGhlIHByb2JhYmlsaXR5IG9mIGNvbGxpc2lvbnMgc2hv dWxkIGJlIHJhcmUNCj5zaW5jZSB0aGUgSURzIHNob3VsZCBiZSBoaWdobHkgdW5pcXVlLCBzbyB3 aHkgbm90IG9wdGltaXplPyIuICBBbHNvLA0KPlJGQzMzMDcgc2VlbXMgdG8gdHJ5IGF2b2lkaW5n IGNvbGxpc2lvbnMgZXZlbiB0aG91Z2ggaXQgcmVjb21tZW5kcyB0aGUNCj51c2Ugb2YgZ29vZCBy YW5kb20gZ3JvdXAgSURzIChhY2NvcmRpbmcgdG8gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2YNCj5T ZWN0aW9uIDQuMy4yKS4gIFNvLCBpdCBzZWVtcyBtb3JlIGNvbnNpc3RlbnQgdG8gbWUgdG8gYXZv aWQNCj5jb2xsaXNpb25zIGluIHRoaXMgY2FzZSBkZXNwaXRlIHRoZSB1c2Ugb2YgcmVhc29uYWJs eSBkaXN0cmlidXRlZCBJRHMuDQo+DQo+ICANCj4NClRoZSByZWFsIHBvaW50IEkgd2FzIHRyeWlu ZyB0byBnZXQgYWNyb3NzIGlzIHRoYXQgTGF5ZXIgMiBtdWx0aWNhc3QgDQphZGRyZXNzIGNvbGxp c2lvbnMgYXJlIGVzc2VudGlhbGx5IHVuYXZvaWRhYmxlLCBidXQgdGhhdCB0aGV5IGFyZSwgYXQg DQpsZWFzdCBpbiB0aGUgbmFtZSBsb29rdXAgY2FzZSwgYmVuaWduLCBlc3BlY2lhbGx5IGFzIGZh ciBhcyBwZXJmb3JtYW5jZSANCmlzIGNvbmNlcm5lZC4gU28gSSB3b3VsZG4ndCBjaGFuZ2UgdGhl IGFsZ29yaXRobS4NCg0KSSBhZ3JlZWQgd2l0aCB0aGUgREFEIGRlY2lzaW9uLCBhbmQgbWFraW5n IHN1cmUgdGhlIGxheWVyIDMgYWRkcmVzc2VzIA0KYXJlIHVuaXF1ZSBmb3IgYSBnaXZlbiBwdXJw b3NlIGlzIGNsZWFybHkgdGhlIHJpZ2h0IGFuc3dlciwgYmVjYXVzZSBhIA0KY29sbGlzaW9uIGNv dWxkIGhhdmUgZGlzYXN0cm91cyBlZmZlY3RzIHVubGVzcyBub2Rlcy9hcHBsaWNhdGlvbnMgYXJl IA0KZXhwZWN0aW5nIGl0Lg0KDQpUaGUgbmFtZSBsb29rdXAgYW5kIE5EIHNvbGljaXRlZCBub2Rl IExheWVyIDMgYWRkcmVzc2VzIGFyZSB0YWtlbiBmcm9tIA0KZGlmZmVyZW50IHNwYWNlcyBmcm9t IGFueSBvZiB0aGUgUkZDMzMwNyBhZGRyZXNzZXMgc28gdGhlcmUgY2FuIG5ldmVyIGJlIA0KYSBj b2xsaXNpb24gYmV0d2VlbiB0aGVzZSBkaWZmZXJlbnQgdHlwZXMgb2YgYWRkcmVzc2VzIGF0IExh eWVyIDMuDQpUaGUgbmFtZSBsb29rdXAgKGFuZCBORCkgc29sdXRpb24gcmVkdWNlcyB0aGUgcHJv YmFiaWxpdHkgb2YgbXVsdGlwbGUgDQpub2RlcyB1c2luZyB0aGUgc2FtZSBMYXllciAzIGFuZCBM YXllciAyIGFkZHJlc3NlcyBmb3IgdGhpcyBwdXJwb3NlIGJ1dCANCmVuc3VyZSB0aGF0IGEgY29s bGlzaW9uIGRvZXNuJ3QgbWF0dGVyLCBhbHRob3VnaCB0aGVyZSB3aWxsIGJlIGEgc21hbGwgDQph bW91bnQgb2Ygd2FzdGVkIGVmZm9ydCBvbiBub2RlcyB3aXRoIExheWVyIDMgY29sbGlzaW9ucy4N Cg0KQXMgZmFyIGFzIEkgY2FuIHNlZSwgdGhlcmUgaXMgYm91bmQgdG8gYmUgYSBzbWFsbCByZXNp ZHVhbCBwcm9iYWJpbGl0eSANCm9mIGEgTGF5ZXIgMiBtdWx0aWNhc3QgYWRkcmVzcyBjb2xsaXNp b24gb24gYWNjb3VudCBvZiB0aGVyZSBiZWluZyBtYW55IA0KbGVzcyBMYXllciAyIG11bHRpY2Fz dCBhZGRyZXNzZXMgdGhhbiBMYXllciAzIG11bHRpY2FzdCBhZGRyZXNzZXMuIEluIA0KdGhlIHZh c3QgbWFqb3JpdHkgb2YgY2FzZXMgdGhpcyB3aWxsIG5vdCBtYXR0ZXIgYmVjYXVzZSBub2RlcyB3 aWxsIA0KcmVjZWl2ZSBhbmQgcHJvY2VzcyBqdXN0IHRoZSBwYWNrZXRzIHRoZXkgd291bGQgaGF2 ZSByZWNlaXZlZCBhbnl3YXkuIA0KVGhlcmUgd2lsbCBiZSBhIHNtYWxsIG51bWJlciBvZiAocmVs YXRpdmVseSkgcGF0aG9sb2dpY2FsIGNhc2VzIHdoZXJlIGEgDQpwYWNrZXQgZ29lcyB0byBhIG51 bWJlciBvZiBsaXN0ZW5lcnMgdGhhdCBhcmVuJ3QgaW50ZXJlc3RlZC4gSG93ZXZlciwgDQplc3Bl Y2lhbGx5IGluIHRoZSBjYXNlIG9mIG5hbWUgbG9va3VwLCB0aGUgbnVtYmVyIG9mIHBhY2tldHMg aW52b2x2ZWQgYXQgDQphbnkgb25lIG5vZGUgaXMgbGlrZWx5IHRvIGJlIHZlcnkgc21hbGwuDQpS ZWdhcmRzLA0KRWx3eW4NCg0KPkl0J3Mgbm90IGEgc3Ryb25nIG9waW5pb24gdGhvdWdoLiAgSWYg YSBtYWpvcml0eSBwcmVmZXJzIGtlZXBpbmcgdGhlDQo+Y3VycmVudCByYW5nZSwgSSB3b24ndCBm aWdodCBhZ2FpbnN0IHRoYXQuDQo+DQo+CQkJCQlKSU5NRUksIFRhdHV5YQ0KPgkJCQkJQ29tbXVu aWNhdGlvbiBQbGF0Zm9ybSBMYWIuDQo+CQkJCQlDb3Jwb3JhdGUgUiZEIENlbnRlciwgVG9zaGli YSBDb3JwLg0KPgkJCQkJamlubWVpQGlzbC5yZGMudG9zaGliYS5jby5qcA0KPiAgDQo+DQo= --===============0581367205== 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 -------------------------------------------------------------------- --===============0581367205==-- From ipv6-bounces@ietf.org Wed Jul 20 18:55:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNTV-0005RN-9o; Wed, 20 Jul 2005 18:55:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNTT-0005Qv-JX for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 18:55:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06558 for ; Wed, 20 Jul 2005 18:55:32 -0400 (EDT) Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvNxK-0001IF-8l for ipv6@ietf.org; Wed, 20 Jul 2005 19:26:30 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DvNTD-0003fq-DM; Wed, 20 Jul 2005 23:55:19 +0100 Message-ID: <42DED698.8000509@dial.pipex.com> Date: Wed, 20 Jul 2005 23:56:24 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pashby, Ronald W CTR NSWCDD-B35" References: <041052AD735329479241C23E0813EB7E9EC874@NAEAMILLEX05VA.nadsusea.nads.navy.mil> In-Reply-To: <041052AD735329479241C23E0813EB7E9EC874@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Content-Type: text/plain; charset=UTF-8; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA06558 Cc: ipv6@ietf.org, jinmei@isl.rdc.toshiba.co.jp Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Fair point about the possible problems - thanks for the explanation. I=20 understand what you mean there now. Unfortunately since there are several independent dynamic and=20 pseudo-dynamic allocation mechanisms in play, you are only going to get=20 absolute guarantees if you partition the group id space further.=20 (RFC2809 has some words on this). Just making the name lookup addresses=20 somewhere in the dynamic area still risks collisions. If you want to go=20 down this path I think one solution would be to overload the group space=20 which is already used for ND OxFFxxxxxx. ND and name lookups would not=20 find occasional clashes a big problem as the Layer 3 addresses differ=20 and the packet rates are low. Name lookups could just use the top 24=20 bits instead of the top 32 bits of the MD5 hash, and collisions would=20 start to be likely with a few hundred nodes on a link. Applications=20 that have a problem can try to avoid this part of the space. The alternative is to turn the problem around and tell applications that=20 are worried to test if anybody else is using the group (check with the=20 MLD queries or send a name lookup NOOP?) and get a different address if=20 there is a collision. The problem is what happens when new nodes arrive=20 - so maybe not? Regards, Elwyn Pashby, Ronald W CTR NSWCDD-B35 wrote: >I disagree that layer2 collisions are unavoidable. If you follow RFC3307= then collisions between dynamically assigned and permanent assigned addr= esses are totally avoidable (like they are intended). The issue here is t= hat this draft does not follow the intent of 3307. > >As far as benign goes, everyone considers the effect of sending "Name Qu= eries" and because of a collision a host that joined "another" group gets= those queries. But the opposite case is the major one. Take for instance= that a multicast group is being used to send large amounts of packets pe= r second. Another host is running a real-time mission critical applicatio= n that it not designed to receive a large number of packets per second. = The second host just happens to join the same (layer 2) group because of = the MD5 hash on its name. Then the host will be flooded with multicast tr= affic and may cause it to fail to perform its real-time task. > >The solution is to insure that certain ranges of address can be used to = guarantee that collision will not happen. > >-----Original Message----- >From: Elwyn Davies [mailto:elwynd@dial.pipex.com] >Sent: Wednesday, July 20, 2005 11:29 >To: jinmei@isl.rdc.toshiba.co.jp >Cc: Elwyn Davies; ipv6@ietf.org; Pashby, Ronald W CTR NSWCDD-B35 >Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt > > > > >JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > =20 > >>>>>>>On Wed, 20 Jul 2005 11:43:45 +0100,=20 >>>>>>>Elwyn Davies said: >>>>>>> =20 >>>>>>> >>>>>>> =20 >>>>>>> >>=20 >> >> =20 >> >>>As I said in my previous posting, I don't think you ought to think >>>of either solicited node multicast groups or these groups as >>>dynamically allocated. The groups exist statically whether any >>>nodes are using them or not. The dynamically allocated ones are >>>(IMO) those that an application needs to create with some guarantee >>>of uniqueness in order to send on. No dynamic allocation is needed >>>for the name lookup addresses. >>> =20 >>> >>> =20 >>> >>Whether it's really a 'dynamically allocated' address or not is just a >>matter of definition. I won't surprise if different people have >>different views on this. I just represented my own interpretation of >>the sense of RFC3307. Of course, I could be wrong, in which case the >>author of the RFC will hopefully correct me. >>=20 >> >> =20 >> >Indeed RFC3307 has to some extent been overtaken by events and the exact= =20 >meaning is now unclear. As you say it doesn't really matter for the=20 >purposes of this discussion. > > =20 > >>In any case, I don't think the definition of 'dynamic' is a real >>issue. The issue is whether it makes sense to try avoiding layer-2 >>and layer-3 collisions for the multicast groups regarding the >>icmp-name-lookup protocol. >>=20 >> >> =20 >> > > =20 > >>In my understanding, a very rough summary of your argument against >>this point is "the probability of collisions should be very rare due >>to the use of MD5 hashing, so don't bother" (correct?). I see the >>point, and I can live with that. >> >>In my undersatnding, however, the trend of the IETF is to not rely on >>that type of arguments and is to try avoiding possible collisions more >>and more explicitly. In fact, we rejected the idea of "duplicate >>interface-ID detection' instead of 'duplicate address detection', >>based on the argument of "the probability of collisions should be rare >>since the IDs should be highly unique, so why not optimize?". Also, >>RFC3307 seems to try avoiding collisions even though it recommends the >>use of good random group IDs (according to the second paragraph of >>Section 4.3.2). So, it seems more consistent to me to avoid >>collisions in this case despite the use of reasonably distributed IDs. >> >>=20 >> >> =20 >> >The real point I was trying to get across is that Layer 2 multicast=20 >address collisions are essentially unavoidable, but that they are, at=20 >least in the name lookup case, benign, especially as far as performance=20 >is concerned. So I wouldn't change the algorithm. > >I agreed with the DAD decision, and making sure the layer 3 addresses=20 >are unique for a given purpose is clearly the right answer, because a=20 >collision could have disastrous effects unless nodes/applications are=20 >expecting it. > >The name lookup and ND solicited node Layer 3 addresses are taken from=20 >different spaces from any of the RFC3307 addresses so there can never be= =20 >a collision between these different types of addresses at Layer 3. >The name lookup (and ND) solution reduces the probability of multiple=20 >nodes using the same Layer 3 and Layer 2 addresses for this purpose but=20 >ensure that a collision doesn't matter, although there will be a small=20 >amount of wasted effort on nodes with Layer 3 collisions. > >As far as I can see, there is bound to be a small residual probability=20 >of a Layer 2 multicast address collision on account of there being many=20 >less Layer 2 multicast addresses than Layer 3 multicast addresses. In=20 >the vast majority of cases this will not matter because nodes will=20 >receive and process just the packets they would have received anyway.=20 >There will be a small number of (relatively) pathological cases where a=20 >packet goes to a number of listeners that aren't interested. However,=20 >especially in the case of name lookup, the number of packets involved at= =20 >any one node is likely to be very small. >Regards, >Elwyn > > =20 > >>It's not a strong opinion though. If a majority prefers keeping the >>current range, I won't fight against that. >> >> JINMEI, Tatuya >> Communication Platform Lab. >> Corporate R&D Center, Toshiba Corp. >> jinmei@isl.rdc.toshiba.co.jp >>=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 Wed Jul 20 19:02:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNa7-0008UV-2s; Wed, 20 Jul 2005 19:02:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNa5-0008Tc-2P for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 19:02:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08467 for ; Wed, 20 Jul 2005 19:02:21 -0400 (EDT) Received: from yamaha-ctcnetlink14.yamaha.co.jp ([218.216.190.126] helo=aphrodite.comm.yamaha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvO3x-0002Dc-FS for ipv6@ietf.org; Wed, 20 Jul 2005 19:33:20 -0400 Received: from aphrodite.comm.yamaha.co.jp by aphrodite.comm.yamaha.co.jp via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 21 Jul 2005 08:02:21 +0900 Received: from localhost (selene [133.176.112.13]) by comm.yamaha.co.jp (8.12.11/8.9.3/CY01) with ESMTP id j6KN299b081909 for ; Thu, 21 Jul 2005 08:02:09 +0900 (JST) (envelope-from hirose@comm.yamaha.co.jp) Date: Thu, 21 Jul 2005 08:01:52 +0900 (JST) Message-Id: <20050721.080152.184461359.hirose@comm.yamaha.co.jp> To: ipv6@ietf.org From: Ryota Hirose In-Reply-To: <42DE90BC.3050403@nasa.gov> References: <20050720.183754.22498937.hirose@comm.yamaha.co.jp> <42DE90BC.3050403@nasa.gov> X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, >From: Hugh LaMaster >Date: Wed, 20 Jul 2005 10:58:20 -0700 > As I read it, RFC2464 says that the maximum *default* MTU is 1500, > and, anything larger than that must be manually configured. It > doesn't say that it is prohibited. RFC2464 says as following: This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. I'm sorry for my poor English knowledge, but I think this sentence permit to decrease MTU from default size by manual configuration. OK, this sentence or others in the section don't prohibit increase MTU. Since decrease MTU is permitted and there is no mention to increase, I understood that the increase MTU is prohibited. Isn't it a common sense? Please refer RFC2467, which is about FDDI. FDDI's MTU is variable by network configuration, but RFC2467 provides the default MTU is 4352 for some reasons. After that, same sentences with RFC2464 follow, but I cannot read as larger MTU than 4352 is permitted. And RFC2461, which is about ND and RS/RA, says about host behavior which receive RA, If the MTU option is present, hosts SHOULD copy the option's value into LinkMTU so long as the value is greater than or equal to the minimum link MTU [IPv6] and does not exceed the default LinkMTU value specified in the link type specific document (e.g., [IPv6-ETHER]). This is prohibited that MTU option exceed the *default* LinkMTU. > > BTW, Jinmei san suggested that KAME, NetBSD and OpenBSD are already > > hacked as above and this behavior may be only FreeBSD problem. > > But, according to RFC2464, FreeBSD behavior is right, and other > > BSDs is wrong. In my environment, Windows XP SP2 accepts larger MTU than 1500 and sends Jumbo Frames. Of course, if the implementation want to use Jumbo Frames, it will have to accept large MTU. Many implemetations work so, and FreeBSD's behavior is a bug from the point of view of users. But, according to RFC2464 and RFC2461 strictly, I think we cannot use Jumbo Frames on GbE. Is an update memorandum about Jumbo Frames necessary, isn't it? Ryota Hirose Yamaha Corporation -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 20 19:16:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNnj-0002KZ-FK; Wed, 20 Jul 2005 19:16:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNnh-0002K3-Ds for ipv6@megatron.ietf.org; Wed, 20 Jul 2005 19:16:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13779 for ; Wed, 20 Jul 2005 19:16:25 -0400 (EDT) Received: from yamaha-ctcnetlink14.yamaha.co.jp ([218.216.190.126] helo=aphrodite.comm.yamaha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvOHX-0004bh-DM for ipv6@ietf.org; Wed, 20 Jul 2005 19:47:24 -0400 Received: from aphrodite.comm.yamaha.co.jp by aphrodite.comm.yamaha.co.jp via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 21 Jul 2005 08:16:22 +0900 Received: from localhost (selene [133.176.112.13]) by comm.yamaha.co.jp (8.12.11/8.9.3/CY01) with ESMTP id j6KNGDbY082096 for ; Thu, 21 Jul 2005 08:16:13 +0900 (JST) (envelope-from hirose@comm.yamaha.co.jp) Date: Thu, 21 Jul 2005 08:16:08 +0900 (JST) Message-Id: <20050721.081608.57792790.hirose@comm.yamaha.co.jp> To: ipv6@ietf.org From: Ryota Hirose In-Reply-To: <20050721.080152.184461359.hirose@comm.yamaha.co.jp> References: <20050720.183754.22498937.hirose@comm.yamaha.co.jp> <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, >From: Ryota Hirose >Date: Thu, 21 Jul 2005 08:01:52 +0900 (JST) > Please refer RFC2467, which is about FDDI. FDDI's MTU is variable by Please refer RFC2497 also. It is about ARCnet. ARCnet's maximum MTU is 60480, but RFC2497 says that it is impractical, so provides that default MTU for IPv6 is 9072. And says, In the presence of a router, this size MAY be changed by a Router Advertisement [DISC] containing an MTU option. If a Router Advertisement is received with an MTU option specifying an MTU larger than 60480, or larger than a manually configured value less than 60480, that MTU option may be logged to system management but MUST be otherwise ignored. RFC2497 use a word 'be changed' instead of 'be reduced', because ARCnet can increase MTU to 60480. Ryota Hirose Yamaha Corporation -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 21 04:20:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWHq-0002a0-Di; Thu, 21 Jul 2005 04:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWHn-0002Zr-Sg for ipv6@megatron.ietf.org; Thu, 21 Jul 2005 04:20:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11109 for ; Thu, 21 Jul 2005 04:20:06 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvWlm-00055R-RB for ipv6@ietf.org; Thu, 21 Jul 2005 04:51:08 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6L8JtHS003139 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 21 Jul 2005 10:19:57 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20050721.080152.184461359.hirose@comm.yamaha.co.jp> References: <20050720.183754.22498937.hirose@comm.yamaha.co.jp> <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Thu, 21 Jul 2005 10:19:56 +0200 To: Ryota Hirose X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 21-jul-2005, at 1:01, Ryota Hirose wrote: >> As I read it, RFC2464 says that the maximum *default* MTU is 1500, >> and, anything larger than that must be manually configured. It >> doesn't say that it is prohibited. > RFC2464 says as following: > This size may be reduced by a Router Advertisement [DISC] > containing an MTU option which specifies a smaller MTU, or by > manual > configuration of each node. > I'm sorry for my poor English knowledge, but I think this sentence > permit to decrease MTU from default size by manual configuration. > OK, this sentence or others in the section don't prohibit increase > MTU. Since decrease MTU is permitted and there is no mention to > increase, I understood that the increase MTU is prohibited. Isn't it > a common sense? Well, that's a philosophical question: is everything that isn't explicitly disallowed allowed by default, or is everything that isn't explicitly allowed disallowed by default? My common sense tells me that the authors of RFC 2464 didn't consider the case where the MTU would legitimately be larger than 1500 bytes. They did consider the case where router advertisements contain an MTU that is apparently incorrect, because it's larger than the standard allows. Ideally, the MTU would be a neighbor discovery option, so that the highest possible MTU can be used between two systems on a subnet, without requiring that all systems on a subnet support the same MTU size. However, this is problematic because switches and hubs also have MTU limitations that can't be discovered this way. In any event, RFC 2464 doesn't say it's disallowed to configure an MTU larger than 1500 bytes on an ethernet subnet, and it also doesn't provide any reasons why doing so would be bad. The only thing it says is that the MTU option in router advertisements can't be used to increase the MTU beyond 1500 bytes. So in my opinion, an implementation that supports jumboframes should use the interface MTU for IPv6 by default, and reduce this MTU for IPv6 to the one in an MTU option in router advertisements, when such an option is received. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 21 07:31:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZGy-0003G4-QB; Thu, 21 Jul 2005 07:31:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZGv-0003Fs-Bs for ipv6@megatron.ietf.org; Thu, 21 Jul 2005 07:31:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21088 for ; Thu, 21 Jul 2005 07:31:24 -0400 (EDT) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvZku-0000YL-S7 for ipv6@ietf.org; Thu, 21 Jul 2005 08:02:27 -0400 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 21 Jul 2005 11:31:18 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Thu, 21 Jul 2005 11:31:05 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Jul 2005 06:31:02 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9EC875@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt Thread-Index: AcWNfizZVUkF1U2FRmiko8Pdz6IvMAAZ+Yvw From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Elwyn Davies" X-OriginalArrivalTime: 21 Jul 2005 11:31:02.0872 (UTC) FILETIME=[ACF66D80:01C58DE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: ipv6@ietf.org, jinmei@isl.rdc.toshiba.co.jp Subject: RE: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.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="===============1561156498==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1561156498== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QWN0dWFsbHksIG15IHByb3Bvc2FsIHRvIEJyaWFuIG9uIHRoZSBkcmFmdCB3YXMgZXhhY3RseSB3 aGF0IHlvdSBzdWdnZXN0ZWQsIG1hcHBpbmcgdGhlIG5hbWUgcXVlcmllcyBpbnRvIHRoZSBTb2xp Y2l0ZWQgTm9kZSBBZGRyZXNzIChTTkEpIHJhbmdlLiBJIHRoaW5rIHRoYXQgaXMgdGhlIGJlc3Qg c29sdXRpb24uIEkgaGF2ZSBhbm90aGVyIGRyYWZ0IHRoYXQgc3VnZ2VzdHMgdGhhdCB0aGUgImR5 bmFtaWMgcmFuZ2UiIGdldHMgYnJva2VuIGludG8gMiBtYWpvciBzZWN0aW9uczogR2xvYmFsIChE QUcpIHNjb3BlZCBhbmQgTm9uLUdsb2JhbCAoREFORykgc2NvcGVkLiBUaGUgbm9uLWdsb2JhbCBy YW5nZSBpcyBmdXJ0aGVyIGJyb2tlbiBkb3duIGludG8gTGluay1Mb2NhbCBhbmQgUmVzZXJ2ZWQu IExpbmstTG9jYWwgaXMgdGhlIHJhbmdlIDB4RjAwMDAwMDAgLSAweEZGRkZGRkZGRiwgd2hpY2gg aW5jbHVkZXMgdGhlIFNOQXMgcGx1cyBzb21lIHJvb20gZm9yIGV4cGFuc2lvbiBmb3IgdGhpbmdz IGxpa2UgdGhlIG5hbWUgcXVlcmllcyBpZiBvdmVybG9hZGluZyB0aGUgU05BcyBpcyBkZWVtZWQg aGFybWZ1bC4gVGhlIHJlc2VydmVkIHJhbmdlIGlzIGZvciBwb3NzaWJsZSB1c2Ugb2YgT3JnYW5p emF0aW9uIHNjb3BlZCBhbmQgU2l0ZSBzY29wZS4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBFbHd5biBEYXZpZXMgW21haWx0bzplbHd5bmRAZGlhbC5waXBleC5jb21dDQpT ZW50OiBXZWRuZXNkYXksIEp1bHkgMjAsIDIwMDUgMTg6NTYNClRvOiBQYXNoYnksIFJvbmFsZCBX IENUUiBOU1dDREQtQjM1DQpDYzogamlubWVpQGlzbC5yZGMudG9zaGliYS5jby5qcDsgaXB2NkBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtaXBuZ3dnLWljbXAt bmFtZS1sb29rdXBzLTEyLnR4dA0KDQoNCkZhaXIgcG9pbnQgYWJvdXQgdGhlIHBvc3NpYmxlIHBy b2JsZW1zIC0gdGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24uICBJIA0KdW5kZXJzdGFuZCB3aGF0 IHlvdSBtZWFuIHRoZXJlIG5vdy4NCg0KVW5mb3J0dW5hdGVseSBzaW5jZSB0aGVyZSBhcmUgc2V2 ZXJhbCBpbmRlcGVuZGVudCBkeW5hbWljIGFuZCANCnBzZXVkby1keW5hbWljIGFsbG9jYXRpb24g bWVjaGFuaXNtcyBpbiBwbGF5LCB5b3UgYXJlIG9ubHkgZ29pbmcgdG8gZ2V0IA0KYWJzb2x1dGUg Z3VhcmFudGVlcyBpZiB5b3UgcGFydGl0aW9uIHRoZSBncm91cCBpZCBzcGFjZSBmdXJ0aGVyLiAN CihSRkMyODA5IGhhcyBzb21lIHdvcmRzIG9uIHRoaXMpLiAgSnVzdCBtYWtpbmcgdGhlIG5hbWUg bG9va3VwIGFkZHJlc3NlcyANCnNvbWV3aGVyZSBpbiB0aGUgZHluYW1pYyBhcmVhIHN0aWxsIHJp c2tzIGNvbGxpc2lvbnMuICBJZiB5b3Ugd2FudCB0byBnbyANCmRvd24gdGhpcyBwYXRoIEkgdGhp bmsgb25lIHNvbHV0aW9uIHdvdWxkIGJlIHRvIG92ZXJsb2FkIHRoZSBncm91cCBzcGFjZSANCndo aWNoIGlzIGFscmVhZHkgdXNlZCBmb3IgTkQgT3hGRnh4eHh4eC4gIE5EIGFuZCBuYW1lIGxvb2t1 cHMgd291bGQgbm90IA0KZmluZCBvY2Nhc2lvbmFsIGNsYXNoZXMgYSBiaWcgcHJvYmxlbSBhcyB0 aGUgTGF5ZXIgMyBhZGRyZXNzZXMgZGlmZmVyIA0KYW5kIHRoZSBwYWNrZXQgcmF0ZXMgYXJlIGxv dy4gIE5hbWUgbG9va3VwcyBjb3VsZCBqdXN0IHVzZSB0aGUgdG9wIDI0IA0KYml0cyBpbnN0ZWFk IG9mIHRoZSB0b3AgMzIgYml0cyBvZiB0aGUgTUQ1IGhhc2gsIGFuZCBjb2xsaXNpb25zIHdvdWxk IA0Kc3RhcnQgdG8gYmUgbGlrZWx5IHdpdGggYSBmZXcgaHVuZHJlZCBub2RlcyBvbiBhIGxpbmsu ICBBcHBsaWNhdGlvbnMgDQp0aGF0IGhhdmUgYSBwcm9ibGVtIGNhbiB0cnkgdG8gYXZvaWQgdGhp cyBwYXJ0IG9mIHRoZSBzcGFjZS4NCg0KVGhlIGFsdGVybmF0aXZlIGlzIHRvIHR1cm4gdGhlIHBy b2JsZW0gYXJvdW5kIGFuZCB0ZWxsIGFwcGxpY2F0aW9ucyB0aGF0IA0KYXJlIHdvcnJpZWQgdG8g dGVzdCBpZiBhbnlib2R5IGVsc2UgaXMgdXNpbmcgdGhlIGdyb3VwIChjaGVjayB3aXRoIHRoZSAN Ck1MRCBxdWVyaWVzIG9yIHNlbmQgYSBuYW1lIGxvb2t1cCBOT09QPykgIGFuZCBnZXQgYSBkaWZm ZXJlbnQgYWRkcmVzcyBpZiANCnRoZXJlIGlzIGEgY29sbGlzaW9uLiBUaGUgcHJvYmxlbSBpcyB3 aGF0IGhhcHBlbnMgd2hlbiBuZXcgbm9kZXMgYXJyaXZlIA0KLSBzbyBtYXliZSBub3Q/DQoNClJl Z2FyZHMsDQpFbHd5bg0KDQoNClBhc2hieSwgUm9uYWxkIFcgQ1RSIE5TV0NERC1CMzUgd3JvdGU6 DQoNCj5JIGRpc2FncmVlIHRoYXQgbGF5ZXIyIGNvbGxpc2lvbnMgYXJlIHVuYXZvaWRhYmxlLiBJ ZiB5b3UgZm9sbG93IFJGQzMzMDcgdGhlbiBjb2xsaXNpb25zIGJldHdlZW4gZHluYW1pY2FsbHkg YXNzaWduZWQgYW5kIHBlcm1hbmVudCBhc3NpZ25lZCBhZGRyZXNzZXMgYXJlIHRvdGFsbHkgYXZv aWRhYmxlIChsaWtlIHRoZXkgYXJlIGludGVuZGVkKS4gVGhlIGlzc3VlIGhlcmUgaXMgdGhhdCB0 aGlzIGRyYWZ0IGRvZXMgbm90IGZvbGxvdyB0aGUgaW50ZW50IG9mIDMzMDcuDQo+DQo+QXMgZmFy IGFzIGJlbmlnbiBnb2VzLCBldmVyeW9uZSBjb25zaWRlcnMgdGhlIGVmZmVjdCBvZiBzZW5kaW5n ICJOYW1lIFF1ZXJpZXMiIGFuZCBiZWNhdXNlIG9mIGEgY29sbGlzaW9uIGEgaG9zdCB0aGF0IGpv aW5lZCAiYW5vdGhlciIgZ3JvdXAgZ2V0cyB0aG9zZSBxdWVyaWVzLiBCdXQgdGhlIG9wcG9zaXRl IGNhc2UgaXMgdGhlIG1ham9yIG9uZS4gVGFrZSBmb3IgaW5zdGFuY2UgdGhhdCBhIG11bHRpY2Fz dCBncm91cCBpcyBiZWluZyB1c2VkIHRvIHNlbmQgbGFyZ2UgYW1vdW50cyBvZiBwYWNrZXRzIHBl ciBzZWNvbmQuIEFub3RoZXIgaG9zdCBpcyBydW5uaW5nIGEgcmVhbC10aW1lIG1pc3Npb24gY3Jp dGljYWwgYXBwbGljYXRpb24gdGhhdCBpdCBub3QgZGVzaWduZWQgdG8gcmVjZWl2ZSBhIGxhcmdl IG51bWJlciBvZiBwYWNrZXRzIHBlciBzZWNvbmQuICBUaGUgc2Vjb25kIGhvc3QganVzdCBoYXBw ZW5zIHRvIGpvaW4gdGhlIHNhbWUgKGxheWVyIDIpIGdyb3VwIGJlY2F1c2Ugb2YgdGhlIE1ENSBo YXNoIG9uIGl0cyBuYW1lLiBUaGVuIHRoZSBob3N0IHdpbGwgYmUgZmxvb2RlZCB3aXRoIG11bHRp Y2FzdCB0cmFmZmljIGFuZCBtYXkgY2F1c2UgaXQgdG8gZmFpbCB0byBwZXJmb3JtIGl0cyByZWFs LXRpbWUgdGFzay4NCj4NCj5UaGUgc29sdXRpb24gaXMgdG8gaW5zdXJlIHRoYXQgY2VydGFpbiBy YW5nZXMgb2YgYWRkcmVzcyBjYW4gYmUgdXNlZCB0byBndWFyYW50ZWUgdGhhdCBjb2xsaXNpb24g d2lsbCBub3QgaGFwcGVuLg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTog RWx3eW4gRGF2aWVzIFttYWlsdG86ZWx3eW5kQGRpYWwucGlwZXguY29tXQ0KPlNlbnQ6IFdlZG5l c2RheSwgSnVseSAyMCwgMjAwNSAxMToyOQ0KPlRvOiBqaW5tZWlAaXNsLnJkYy50b3NoaWJhLmNv LmpwDQo+Q2M6IEVsd3luIERhdmllczsgaXB2NkBpZXRmLm9yZzsgUGFzaGJ5LCBSb25hbGQgVyBD VFIgTlNXQ0RELUIzNQ0KPlN1YmplY3Q6IFJlOiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWlwbmd3 Zy1pY21wLW5hbWUtbG9va3Vwcy0xMi50eHQNCj4NCj4NCj4NCj4NCj5KSU5NRUkgVGF0dXlhIC8g 56We5piO6YGU5ZOJIHdyb3RlOg0KPg0KPiAgDQo+DQo+Pj4+Pj4+T24gV2VkLCAyMCBKdWwgMjAw NSAxMTo0Mzo0NSArMDEwMCwgDQo+Pj4+Pj4+RWx3eW4gRGF2aWVzIDxlbHd5bmRAZGlhbC5waXBl eC5jb20+IHNhaWQ6DQo+Pj4+Pj4+ICAgICAgICAgICANCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAg ICAgICAgIA0KPj4+Pj4+Pg0KPj4gDQo+Pg0KPj4gICAgDQo+Pg0KPj4+QXMgSSBzYWlkIGluIG15 IHByZXZpb3VzIHBvc3RpbmcsIEkgZG9uJ3QgdGhpbmsgeW91IG91Z2h0IHRvIHRoaW5rDQo+Pj5v ZiBlaXRoZXIgc29saWNpdGVkIG5vZGUgbXVsdGljYXN0IGdyb3VwcyBvciB0aGVzZSBncm91cHMg YXMNCj4+PmR5bmFtaWNhbGx5IGFsbG9jYXRlZC4gIFRoZSBncm91cHMgZXhpc3Qgc3RhdGljYWxs eSB3aGV0aGVyIGFueQ0KPj4+bm9kZXMgYXJlIHVzaW5nIHRoZW0gb3Igbm90LiAgVGhlIGR5bmFt aWNhbGx5IGFsbG9jYXRlZCBvbmVzIGFyZQ0KPj4+KElNTykgdGhvc2UgdGhhdCBhbiBhcHBsaWNh dGlvbiBuZWVkcyB0byBjcmVhdGUgd2l0aCBzb21lIGd1YXJhbnRlZQ0KPj4+b2YgdW5pcXVlbmVz cyBpbiBvcmRlciB0byBzZW5kIG9uLiBObyBkeW5hbWljIGFsbG9jYXRpb24gaXMgbmVlZGVkDQo+ Pj5mb3IgdGhlIG5hbWUgbG9va3VwIGFkZHJlc3Nlcy4NCj4+PiAgIA0KPj4+DQo+Pj4gICAgICAN Cj4+Pg0KPj5XaGV0aGVyIGl0J3MgcmVhbGx5IGEgJ2R5bmFtaWNhbGx5IGFsbG9jYXRlZCcgYWRk cmVzcyBvciBub3QgaXMganVzdCBhDQo+Pm1hdHRlciBvZiBkZWZpbml0aW9uLiAgSSB3b24ndCBz dXJwcmlzZSBpZiBkaWZmZXJlbnQgcGVvcGxlIGhhdmUNCj4+ZGlmZmVyZW50IHZpZXdzIG9uIHRo aXMuICBJIGp1c3QgcmVwcmVzZW50ZWQgbXkgb3duIGludGVycHJldGF0aW9uIG9mDQo+PnRoZSBz ZW5zZSBvZiBSRkMzMzA3LiAgT2YgY291cnNlLCBJIGNvdWxkIGJlIHdyb25nLCBpbiB3aGljaCBj YXNlIHRoZQ0KPj5hdXRob3Igb2YgdGhlIFJGQyB3aWxsIGhvcGVmdWxseSBjb3JyZWN0IG1lLg0K Pj4gDQo+Pg0KPj4gICAgDQo+Pg0KPkluZGVlZCBSRkMzMzA3IGhhcyB0byBzb21lIGV4dGVudCBi ZWVuIG92ZXJ0YWtlbiBieSBldmVudHMgYW5kIHRoZSBleGFjdCANCj5tZWFuaW5nIGlzIG5vdyB1 bmNsZWFyLiBBcyB5b3Ugc2F5IGl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlciBmb3IgdGhlIA0KPnB1 cnBvc2VzIG9mIHRoaXMgZGlzY3Vzc2lvbi4NCj4NCj4gIA0KPg0KPj5JbiBhbnkgY2FzZSwgSSBk b24ndCB0aGluayB0aGUgZGVmaW5pdGlvbiBvZiAnZHluYW1pYycgaXMgYSByZWFsDQo+Pmlzc3Vl LiAgVGhlIGlzc3VlIGlzIHdoZXRoZXIgaXQgbWFrZXMgc2Vuc2UgdG8gdHJ5IGF2b2lkaW5nIGxh eWVyLTINCj4+YW5kIGxheWVyLTMgY29sbGlzaW9ucyBmb3IgdGhlIG11bHRpY2FzdCBncm91cHMg cmVnYXJkaW5nIHRoZQ0KPj5pY21wLW5hbWUtbG9va3VwIHByb3RvY29sLg0KPj4gDQo+Pg0KPj4g ICAgDQo+Pg0KPg0KPiAgDQo+DQo+PkluIG15IHVuZGVyc3RhbmRpbmcsIGEgdmVyeSByb3VnaCBz dW1tYXJ5IG9mIHlvdXIgYXJndW1lbnQgYWdhaW5zdA0KPj50aGlzIHBvaW50IGlzICJ0aGUgcHJv YmFiaWxpdHkgb2YgY29sbGlzaW9ucyBzaG91bGQgYmUgdmVyeSByYXJlIGR1ZQ0KPj50byB0aGUg dXNlIG9mIE1ENSBoYXNoaW5nLCBzbyBkb24ndCBib3RoZXIiIChjb3JyZWN0PykuICBJIHNlZSB0 aGUNCj4+cG9pbnQsIGFuZCBJIGNhbiBsaXZlIHdpdGggdGhhdC4NCj4+DQo+PkluIG15IHVuZGVy c2F0bmRpbmcsIGhvd2V2ZXIsIHRoZSB0cmVuZCBvZiB0aGUgSUVURiBpcyB0byBub3QgcmVseSBv bg0KPj50aGF0IHR5cGUgb2YgYXJndW1lbnRzIGFuZCBpcyB0byB0cnkgYXZvaWRpbmcgcG9zc2li bGUgY29sbGlzaW9ucyBtb3JlDQo+PmFuZCBtb3JlIGV4cGxpY2l0bHkuICBJbiBmYWN0LCB3ZSBy ZWplY3RlZCB0aGUgaWRlYSBvZiAiZHVwbGljYXRlDQo+PmludGVyZmFjZS1JRCBkZXRlY3Rpb24n IGluc3RlYWQgb2YgJ2R1cGxpY2F0ZSBhZGRyZXNzIGRldGVjdGlvbicsDQo+PmJhc2VkIG9uIHRo ZSBhcmd1bWVudCBvZiAidGhlIHByb2JhYmlsaXR5IG9mIGNvbGxpc2lvbnMgc2hvdWxkIGJlIHJh cmUNCj4+c2luY2UgdGhlIElEcyBzaG91bGQgYmUgaGlnaGx5IHVuaXF1ZSwgc28gd2h5IG5vdCBv cHRpbWl6ZT8iLiAgQWxzbywNCj4+UkZDMzMwNyBzZWVtcyB0byB0cnkgYXZvaWRpbmcgY29sbGlz aW9ucyBldmVuIHRob3VnaCBpdCByZWNvbW1lbmRzIHRoZQ0KPj51c2Ugb2YgZ29vZCByYW5kb20g Z3JvdXAgSURzIChhY2NvcmRpbmcgdG8gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2YNCj4+U2VjdGlv biA0LjMuMikuICBTbywgaXQgc2VlbXMgbW9yZSBjb25zaXN0ZW50IHRvIG1lIHRvIGF2b2lkDQo+ PmNvbGxpc2lvbnMgaW4gdGhpcyBjYXNlIGRlc3BpdGUgdGhlIHVzZSBvZiByZWFzb25hYmx5IGRp c3RyaWJ1dGVkIElEcy4NCj4+DQo+PiANCj4+DQo+PiAgICANCj4+DQo+VGhlIHJlYWwgcG9pbnQg SSB3YXMgdHJ5aW5nIHRvIGdldCBhY3Jvc3MgaXMgdGhhdCBMYXllciAyIG11bHRpY2FzdCANCj5h ZGRyZXNzIGNvbGxpc2lvbnMgYXJlIGVzc2VudGlhbGx5IHVuYXZvaWRhYmxlLCBidXQgdGhhdCB0 aGV5IGFyZSwgYXQgDQo+bGVhc3QgaW4gdGhlIG5hbWUgbG9va3VwIGNhc2UsIGJlbmlnbiwgZXNw ZWNpYWxseSBhcyBmYXIgYXMgcGVyZm9ybWFuY2UgDQo+aXMgY29uY2VybmVkLiBTbyBJIHdvdWxk bid0IGNoYW5nZSB0aGUgYWxnb3JpdGhtLg0KPg0KPkkgYWdyZWVkIHdpdGggdGhlIERBRCBkZWNp c2lvbiwgYW5kIG1ha2luZyBzdXJlIHRoZSBsYXllciAzIGFkZHJlc3NlcyANCj5hcmUgdW5pcXVl IGZvciBhIGdpdmVuIHB1cnBvc2UgaXMgY2xlYXJseSB0aGUgcmlnaHQgYW5zd2VyLCBiZWNhdXNl IGEgDQo+Y29sbGlzaW9uIGNvdWxkIGhhdmUgZGlzYXN0cm91cyBlZmZlY3RzIHVubGVzcyBub2Rl cy9hcHBsaWNhdGlvbnMgYXJlIA0KPmV4cGVjdGluZyBpdC4NCj4NCj5UaGUgbmFtZSBsb29rdXAg YW5kIE5EIHNvbGljaXRlZCBub2RlIExheWVyIDMgYWRkcmVzc2VzIGFyZSB0YWtlbiBmcm9tIA0K PmRpZmZlcmVudCBzcGFjZXMgZnJvbSBhbnkgb2YgdGhlIFJGQzMzMDcgYWRkcmVzc2VzIHNvIHRo ZXJlIGNhbiBuZXZlciBiZSANCj5hIGNvbGxpc2lvbiBiZXR3ZWVuIHRoZXNlIGRpZmZlcmVudCB0 eXBlcyBvZiBhZGRyZXNzZXMgYXQgTGF5ZXIgMy4NCj5UaGUgbmFtZSBsb29rdXAgKGFuZCBORCkg c29sdXRpb24gcmVkdWNlcyB0aGUgcHJvYmFiaWxpdHkgb2YgbXVsdGlwbGUgDQo+bm9kZXMgdXNp bmcgdGhlIHNhbWUgTGF5ZXIgMyBhbmQgTGF5ZXIgMiBhZGRyZXNzZXMgZm9yIHRoaXMgcHVycG9z ZSBidXQgDQo+ZW5zdXJlIHRoYXQgYSBjb2xsaXNpb24gZG9lc24ndCBtYXR0ZXIsIGFsdGhvdWdo IHRoZXJlIHdpbGwgYmUgYSBzbWFsbCANCj5hbW91bnQgb2Ygd2FzdGVkIGVmZm9ydCBvbiBub2Rl cyB3aXRoIExheWVyIDMgY29sbGlzaW9ucy4NCj4NCj5BcyBmYXIgYXMgSSBjYW4gc2VlLCB0aGVy ZSBpcyBib3VuZCB0byBiZSBhIHNtYWxsIHJlc2lkdWFsIHByb2JhYmlsaXR5IA0KPm9mIGEgTGF5 ZXIgMiBtdWx0aWNhc3QgYWRkcmVzcyBjb2xsaXNpb24gb24gYWNjb3VudCBvZiB0aGVyZSBiZWlu ZyBtYW55IA0KPmxlc3MgTGF5ZXIgMiBtdWx0aWNhc3QgYWRkcmVzc2VzIHRoYW4gTGF5ZXIgMyBt dWx0aWNhc3QgYWRkcmVzc2VzLiBJbiANCj50aGUgdmFzdCBtYWpvcml0eSBvZiBjYXNlcyB0aGlz IHdpbGwgbm90IG1hdHRlciBiZWNhdXNlIG5vZGVzIHdpbGwgDQo+cmVjZWl2ZSBhbmQgcHJvY2Vz cyBqdXN0IHRoZSBwYWNrZXRzIHRoZXkgd291bGQgaGF2ZSByZWNlaXZlZCBhbnl3YXkuIA0KPlRo ZXJlIHdpbGwgYmUgYSBzbWFsbCBudW1iZXIgb2YgKHJlbGF0aXZlbHkpIHBhdGhvbG9naWNhbCBj YXNlcyB3aGVyZSBhIA0KPnBhY2tldCBnb2VzIHRvIGEgbnVtYmVyIG9mIGxpc3RlbmVycyB0aGF0 IGFyZW4ndCBpbnRlcmVzdGVkLiBIb3dldmVyLCANCj5lc3BlY2lhbGx5IGluIHRoZSBjYXNlIG9m IG5hbWUgbG9va3VwLCB0aGUgbnVtYmVyIG9mIHBhY2tldHMgaW52b2x2ZWQgYXQgDQo+YW55IG9u ZSBub2RlIGlzIGxpa2VseSB0byBiZSB2ZXJ5IHNtYWxsLg0KPlJlZ2FyZHMsDQo+RWx3eW4NCj4N Cj4gIA0KPg0KPj5JdCdzIG5vdCBhIHN0cm9uZyBvcGluaW9uIHRob3VnaC4gIElmIGEgbWFqb3Jp dHkgcHJlZmVycyBrZWVwaW5nIHRoZQ0KPj5jdXJyZW50IHJhbmdlLCBJIHdvbid0IGZpZ2h0IGFn YWluc3QgdGhhdC4NCj4+DQo+PgkJCQkJSklOTUVJLCBUYXR1eWENCj4+CQkJCQlDb21tdW5pY2F0 aW9uIFBsYXRmb3JtIExhYi4NCj4+CQkJCQlDb3Jwb3JhdGUgUiZEIENlbnRlciwgVG9zaGliYSBD b3JwLg0KPj4JCQkJCWppbm1laUBpc2wucmRjLnRvc2hpYmEuY28uanANCj4+IA0KPj4NCj4+ICAg IA0KPj4NCg== --===============1561156498== 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 -------------------------------------------------------------------- --===============1561156498==-- From ipv6-bounces@ietf.org Thu Jul 21 15:51:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvh4O-0001rA-Uv; Thu, 21 Jul 2005 15:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvh3X-0001At-AW; Thu, 21 Jul 2005 15:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03668; Thu, 21 Jul 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvhXZ-0000U7-3v; Thu, 21 Jul 2005 16:21:09 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dvh3S-0003Ws-3M; Thu, 21 Jul 2005 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, 21 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-link-scoped-mcast-09.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: , Sender: ipv6-bounces@ietf.org 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 : A Method for Generating Link Scoped IPv6 Multicast Addresses Author(s) : J. Park, et al. Filename : draft-ietf-ipv6-link-scoped-mcast-09.txt Pages : 7 Date : 2005-7-21 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate their unique multicast addresses automatically without conflicts. Basically, this document proposes an alternative method for creating link-local multicast addresses over a known method like unicast-prefix-based IPv6 multicast addresses. It is preferred to use this method for link-local scope rather than unicast- prefix-based IPv6 multicast addresses. This memo update RFC3306. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-09.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-link-scoped-mcast-09.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-link-scoped-mcast-09.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: <2005-7-21114253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-link-scoped-mcast-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-21114253.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 Jul 21 16:53:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvi2n-0005s3-Oz; Thu, 21 Jul 2005 16:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvi2l-0005rJ-1o for ipv6@megatron.ietf.org; Thu, 21 Jul 2005 16:53:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01014 for ; Thu, 21 Jul 2005 16:53:18 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DviWl-0003qb-Ak for ipv6@ietf.org; Thu, 21 Jul 2005 17:24:27 -0400 Received: from jurassic.eng.sun.com ([129.146.224.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j6LKr53t005334; Thu, 21 Jul 2005 13:53:05 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j6LKr41L952097; Thu, 21 Jul 2005 13:53:05 -0700 (PDT) Message-Id: <200507212053.j6LKr41L952097@jurassic.eng.sun.com> Date: Thu, 21 Jul 2005 13:52:07 -0700 (PDT) From: Samita Chakrabarti To: brian.haley@hp.com, ipv6@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0lWm31bf/63tK1PANzEvMg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: julien.laganier@sun.com, erik.nordmark@sun.com, ipv6@ietf.org, samita.chakrabarti@eng.sun.com Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello Brian: > > Title : IPv6 Socket API for source address selection > > Author(s) : E. Nordmark, et al. > > Filename : draft-chakrabarti-ipv6-addrselect-api-03.txt > > Hi Samita, Erik, and Julien, > > Didn't see this sent to the IPv6 ML, but sending comments here, most are > editorial. Thanks for the comment. Yes, we published the 3rd revision of IPv6 address selection API draft. I don't know why it did not get announced at the IPv6 ML. We intend to publish this document as an individual RFC. The document is under review by some of the IPv6 API authors. But any input from the wg is also appreciated very much by the authors. > ------------------------------------------------------------------------ > Overall comment: > > 1. The draft talks about setting flag X and flag not-X, but the only > place I see where this can happen is trying to set these together: > > IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA > AI_PREFER_SRC_CGA | AI_PREFER_SRC_NONCGA > > Am I missing something? Can I somehow turn-off the use of Care-of > Addresses as source addresses? Maybe it's implied that if I don't set > the flag in the setsockopt()/getaddrinfo() call that it turns-off using > that type of source address? > > ------------------------------------------------------------------------ The combination of flag X and not-X is not allowed - only one should be set at one time, becuase one packet has one source address. The default flags are described in section 7. For example, by default *_SRC_HOME is the choice of flag, ( it means COA address is not used by default as source address), but one can change that by using setsockopt() with *_SRC_COA. > Section 4: > > . > > Not in6.h? > IPV6 Socket options are defined in netinet/in.h i,e. IPV6_HOPLIMIT, IPV6_NEXTHDR etc. Thanks for the careful review for editorial changes. We will review them to incorporate in the document. > IPv4-mapped IPv6 addresses, which are IPv4 addresses in a form that > can be used on an AF_INET6 socket, are supported in this API. In > some cases the IPv4-mapped addresses may not make much sense because > the attributes are IPv6 specific. For example, IPv6 temporary > addresses are not the same as private IPv4 addresses. However, the > IPv4 mapped-address support may be useful for mobile home address and > care-of-address. At this point it is not understood whether this API > has any value to IPv4 addresses or AF_INET family of sockets. > > The second to last sentence here is confusing (regarding mobile), can > you explain what you meant? It was discussed in the ipv6 list sometimes ago that IPV4-mapped IPv6 addresses may be useful for home-address and COA for IPv4 and IPV6 interoperability. It is not well understood, but I think it is possible that a MIPv4 compliant dual-stack node may want to comunicate with a IPv6 address. > ------------------------------------------------------------------------ > Section 10: > > Sometimes an application may have a requirement to only use address > /address/an address/ > > ------------------------------------------------------------------------ > The verification of temporary vs. public, home vs. care-of, CGA vs. > not, are performed by a new function defined for this purpose: > > #include > > Not in6.h? > You mean ip6.h? ip6.h is mainly for advanced API. But this document is more of an extension to Base API. In that context, may be a choice. On the otherhand, all the address testing macros are in netinet/in.h. Good catch! Perhaps IPv6 Socket API authors can shine light on this. Thanks again, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 21 17:40:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvimG-0007kv-So; Thu, 21 Jul 2005 17:40:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvimE-0007kc-6d for ipv6@megatron.ietf.org; Thu, 21 Jul 2005 17:40:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14344 for ; Thu, 21 Jul 2005 17:40:19 -0400 (EDT) Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvjGK-0001hW-5V for ipv6@ietf.org; Thu, 21 Jul 2005 18:11:29 -0400 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by atlrel7.hp.com (Postfix) with ESMTP id 5548041B; Thu, 21 Jul 2005 17:40:15 -0400 (EDT) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id CC79D26A6; Thu, 21 Jul 2005 17:40:14 -0400 (EDT) Received: from [16.116.104.104] by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id RAA12264; Thu, 21 Jul 2005 17:40:14 -0400 (EDT) Message-ID: <42E0163D.8060903@hp.com> Date: Thu, 21 Jul 2005 17:40:13 -0400 From: Vlad Yasevich User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050701) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti References: <200507212053.j6LKr41L952097@jurassic.eng.sun.com> In-Reply-To: <200507212053.j6LKr41L952097@jurassic.eng.sun.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: julien.laganier@sun.com, brian.haley@hp.com, erik.nordmark@sun.com, ipv6@ietf.org Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>------------------------------------------------------------------------ >> The verification of temporary vs. public, home vs. care-of, CGA vs. >> not, are performed by a new function defined for this purpose: >> >> #include >> >>Not in6.h? >> > > > You mean ip6.h? > ip6.h is mainly for advanced API. But this document is more of an > extension to Base API. In that context, may > be a choice. On the otherhand, all the address testing macros are > in netinet/in.h. > > Good catch! Perhaps IPv6 Socket API authors can shine light on this. > > Thanks again, > -Samita > I'd vote for netinet/in.h Some implementations have netinet/in6.h, but that's really an implemenation choice. Using netinet/in.h should work for ipv4 and ipv6. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 21 17:48:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvitw-00058M-Qa; Thu, 21 Jul 2005 17:48:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvitt-00054p-LE for ipv6@megatron.ietf.org; Thu, 21 Jul 2005 17:48:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15229 for ; Thu, 21 Jul 2005 17:48:15 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvjNx-0002Dg-RC for ipv6@ietf.org; Thu, 21 Jul 2005 18:19:25 -0400 Received: from jurassic.eng.sun.com ([129.146.106.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6LLmCr3004855; Thu, 21 Jul 2005 15:48:13 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j6LLmC5M978290; Thu, 21 Jul 2005 14:48:12 -0700 (PDT) Message-Id: <200507212148.j6LLmC5M978290@jurassic.eng.sun.com> Date: Thu, 21 Jul 2005 14:47:14 -0700 (PDT) From: Samita Chakrabarti To: vladislav.yasevich@hp.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XX9OGOOL2oxMJn+1RvTXdA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: brian.haley@hp.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > >>------------------------------------------------------------------------ > >> The verification of temporary vs. public, home vs. care-of, CGA vs. > >> not, are performed by a new function defined for this purpose: > >> > >> #include > >> > >>Not in6.h? > >> > > > > > > You mean ip6.h? > > ip6.h is mainly for advanced API. But this document is more of an > > extension to Base API. In that context, may > > be a choice. On the otherhand, all the address testing macros are > > in netinet/in.h. > > > > Good catch! Perhaps IPv6 Socket API authors can shine light on this. > > > > Thanks again, > > -Samita > > > > I'd vote for netinet/in.h > > Some implementations have netinet/in6.h, but that's really an > implemenation choice. Using netinet/in.h should work for ipv4 and ipv6. > > -vlad > It makes more sense. Agreed. Thanks, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 21 21:33:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvmPv-0004yb-6D; Thu, 21 Jul 2005 21:33:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvmPt-0004yN-F3 for ipv6@megatron.ietf.org; Thu, 21 Jul 2005 21:33:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09193 for ; Thu, 21 Jul 2005 21:33:31 -0400 (EDT) Received: from yamaha-ctcnetlink14.yamaha.co.jp ([218.216.190.126] helo=aphrodite.comm.yamaha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvmu1-0000JD-96 for ipv6@ietf.org; Thu, 21 Jul 2005 22:04:42 -0400 Received: from aphrodite.comm.yamaha.co.jp by aphrodite.comm.yamaha.co.jp via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Fri, 22 Jul 2005 10:33:30 +0900 Received: from localhost (selene [133.176.112.13]) by comm.yamaha.co.jp (8.12.11/8.9.3/CY01) with ESMTP id j6M1Wrm8006786; Fri, 22 Jul 2005 10:32:57 +0900 (JST) (envelope-from hirose@comm.yamaha.co.jp) Date: Fri, 22 Jul 2005 10:32:48 +0900 (JST) Message-Id: <20050722.103248.35008368.hirose@comm.yamaha.co.jp> To: iljitsch@muada.com From: Ryota Hirose In-Reply-To: References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, >From: Iljitsch van Beijnum >Date: Thu, 21 Jul 2005 10:19:56 +0200 > My common sense tells me that the authors of RFC 2464 didn't consider > the case where the MTU would legitimately be larger than 1500 bytes. > They did consider the case where router advertisements contain an MTU > that is apparently incorrect, because it's larger than the standard > allows. I think so. When RFC2464 was issued, GbE and Jumbo Frames were not so deloied, the authors must have believed that the maximum MTU of ehternet is 1500. It was reasonable at the time. > So in my opinion, an implementation that supports jumboframes should > use the interface MTU for IPv6 by default, and reduce this MTU for > IPv6 to the one in an MTU option in router advertisements, when such > an option is received. Yes, your idea is a realistic, and also equal to almost current implementations, I think. BTW, suppose following netowrk. Internet | ROUTER | | 100BASE-TX / MTU=1500 | GbE-SWITCH | | | | 1000BASE-T / MTU=9018 | | HOST1 HOST2 HOST1, HOST2 and GbE-SWITCH support 1000BASE-T and Jumbo Frames, but ROUTER has only 100BASE-TX interfaces and doesn't support Jumbo Frames. In this network, ROUTER will send RA. If the MTU option, which value is 1500, is included in RA, HOST1 and HOST2 will accept it, and are disabled Jumbo Frames. So, if we want to use Jumbo Frambes between HOSTs, (1) HOSTs must neglect MTU option, (2) ROUTER must send RA without MTU option, (3) or ROUTER must send RA with MTU option which value is 9018, illegal MTU for ROUTER itself. (2) RA without MTU option is always valid. But (1) neglect MTU option, or (3) MTU option with illegal value for sender itself, are acceptable? Ryota Hirose Yamaha Corporation -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 00:51:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvpUz-0006iz-QJ; Fri, 22 Jul 2005 00:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvpUx-0006fD-27 for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 00:50:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20611 for ; Fri, 22 Jul 2005 00:50:56 -0400 (EDT) Received: from smta01.mail.ozemail.net ([203.103.165.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvpz6-00019Z-Id for ipv6@ietf.org; Fri, 22 Jul 2005 01:22:10 -0400 Received: from ubu.nosense.org ([210.84.224.184]) by smta01.mail.ozemail.net with ESMTP id <20050722045041.FUHC6478.smta01.mail.ozemail.net@ubu.nosense.org>; Fri, 22 Jul 2005 04:50:41 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 08D7E62AAE; Fri, 22 Jul 2005 14:20:38 +0930 (CST) Date: Fri, 22 Jul 2005 14:20:37 +0930 From: Mark Smith To: Ryota Hirose Message-Id: <20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050722.103248.35008368.hirose@comm.yamaha.co.jp> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; 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.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: iljitsch@muada.com, ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, On Fri, 22 Jul 2005 10:32:48 +0900 (JST) Ryota Hirose wrote: > Hi, > > >From: Iljitsch van Beijnum > >Date: Thu, 21 Jul 2005 10:19:56 +0200 > > > My common sense tells me that the authors of RFC 2464 didn't consider > > the case where the MTU would legitimately be larger than 1500 bytes. > > They did consider the case where router advertisements contain an MTU > > that is apparently incorrect, because it's larger than the standard > > allows. > > > Yes, your idea is a realistic, and also equal to almost current > implementations, I think. > > BTW, suppose following netowrk. > > Internet > | > ROUTER > | > | 100BASE-TX / MTU=1500 > | > GbE-SWITCH > | | > | | 1000BASE-T / MTU=9018 > | | > HOST1 HOST2 > > HOST1, HOST2 and GbE-SWITCH support 1000BASE-T and Jumbo Frames, but > ROUTER has only 100BASE-TX interfaces and doesn't support Jumbo > Frames. In this network, ROUTER will send RA. If the MTU option, > which value is 1500, is included in RA, HOST1 and HOST2 will accept > it, and are disabled Jumbo Frames. So, if we want to use Jumbo > Frambes between HOSTs, (1) HOSTs must neglect MTU option, (2) ROUTER > must send RA without MTU option, (3) or ROUTER must send RA with MTU > option which value is 9018, illegal MTU for ROUTER itself. > > (2) RA without MTU option is always valid. But (1) neglect MTU > option, or (3) MTU option with illegal value for sender itself, are > acceptable? > I'd think not, probably in either (1) or (3), as an interface MTU value implies that the other devices attached to the same segment / link can also receive (and process) the MTU sized frames. To support differing MTU values on a single link/segment, each node would have to somehow keep track of the Maximum Receive Unit value of its link/segment neighbours. PPP supports doing this, and is able to do it because a level of layer 2 parameter negotiation goes on before the link is brought up. It is also simple to do because there is only one neighbour. For this sort of thing to be supported on a multi-access media, such as an ethernet, I'd think some sort of similar, per neighbour, layer 2 parameter negotiation of discovery protocol would have to be developed. A solution for your specific scenario would be to have some way of specifying differing MTUs for onlink and offlink destinations, possibly in the RAs from the router, such that offlink traffic, which goes via the router, uses a MTU smaller than or equal to the MRU MTU of the router's interface. It may be worth developing something like this if your scenario is common enough. Initially I though it may not be, however, thinking about it a bit more I could see this set up might be fairly typical for residential broadband scenarios in the future. 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 Fri Jul 22 01:39:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvqGL-00039I-K5; Fri, 22 Jul 2005 01:39:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvqGH-00039B-UV for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 01:39:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22638 for ; Fri, 22 Jul 2005 01:39:52 -0400 (EDT) Received: from smta03.mail.ozemail.net ([203.103.165.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvqkS-00039h-PO for ipv6@ietf.org; Fri, 22 Jul 2005 02:11:05 -0400 Received: from ubu.nosense.org ([210.84.224.184]) by smta03.mail.ozemail.net with ESMTP id <20050722053944.PWUP24950.smta03.mail.ozemail.net@ubu.nosense.org>; Fri, 22 Jul 2005 05:39:44 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id D0B0862AAE; Fri, 22 Jul 2005 15:09:42 +0930 (CST) Date: Fri, 22 Jul 2005 15:09:42 +0930 From: Mark Smith To: Mark Smith Message-Id: <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; 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.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: iljitsch@muada.com, ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Fri, 22 Jul 2005 14:20:37 +0930 Mark Smith wrote: > Hi, > > On Fri, 22 Jul 2005 10:32:48 +0900 (JST) > Ryota Hirose wrote: > > > Hi, > > > > >From: Iljitsch van Beijnum > > >Date: Thu, 21 Jul 2005 10:19:56 +0200 > > > > > My common sense tells me that the authors of RFC 2464 didn't consider > > > the case where the MTU would legitimately be larger than 1500 bytes. > > > They did consider the case where router advertisements contain an MTU > > > that is apparently incorrect, because it's larger than the standard > > > allows. > > > > > > Yes, your idea is a realistic, and also equal to almost current > > implementations, I think. > > > > BTW, suppose following netowrk. > > > > Internet > > | > > ROUTER > > | > > | 100BASE-TX / MTU=1500 > > | > > GbE-SWITCH > > | | > > | | 1000BASE-T / MTU=9018 > > | | > > HOST1 HOST2 > > > > HOST1, HOST2 and GbE-SWITCH support 1000BASE-T and Jumbo Frames, but > > ROUTER has only 100BASE-TX interfaces and doesn't support Jumbo > > Frames. In this network, ROUTER will send RA. If the MTU option, > > which value is 1500, is included in RA, HOST1 and HOST2 will accept > > it, and are disabled Jumbo Frames. So, if we want to use Jumbo > > Frambes between HOSTs, (1) HOSTs must neglect MTU option, (2) ROUTER > > must send RA without MTU option, (3) or ROUTER must send RA with MTU > > option which value is 9018, illegal MTU for ROUTER itself. > > > > (2) RA without MTU option is always valid. But (1) neglect MTU > > option, or (3) MTU option with illegal value for sender itself, are > > acceptable? > > > > I'd think not, probably in either (1) or (3), as an interface MTU value > implies that the other devices attached to the same segment / link can > also receive (and process) the MTU sized frames. > > To support differing MTU values on a single link/segment, each node > would have to somehow keep track of the Maximum Receive Unit value of > its link/segment neighbours. PPP supports doing this, and is able to do > it because a level of layer 2 parameter negotiation goes on before the > link is brought up. It is also simple to do because there is only one > neighbour. > > For this sort of thing to be supported on a multi-access media, such as > an ethernet, I'd think some sort of similar, per neighbour, layer 2 > parameter negotiation of discovery protocol would have to be developed. > Thinking about this a bit more, this could probably be fairly easy to achieve by creating a "onlink-MRU" or "interface-MRU" option for ND Neighbour Advertisements. There'd need to be some logic in how a sending node selects the size of the packets that it sends to a neighbour, based on comparing the values of its own local interface MTU, the link's MTU as announced in the RA(s) and the target neighbours announced onlink-MRU, if it announces one. > A solution for your specific scenario would be to have some way of > specifying differing MTUs for onlink and offlink destinations, possibly > in the RAs from the router, such that offlink traffic, which goes via > the router, uses a MTU smaller than or equal to the MRU MTU of the > router's interface. It may be worth developing something like this if > your scenario is common enough. Initially I though it may not be, > however, thinking about it a bit more I could see this set up might be > fairly typical for residential broadband scenarios in the future. > A ND RA option, indicating the "router-MRU" or "offlink-MTU" value might be necessary and useful also. Necessary if nodes don't issue ND NSes for routers if they have already learnt the router's Link layer address via the RA. It may also be useful to have an onlink-MRU option as well, to allow for local traffic targetted at the router's onlink interface address(es), which may be used for administrative access to the router, although probably not necessary for the amount of onlink traffic a router receives. Useful if the router only has one other link, e.g., a link to the Internet, and the MTU of that link is smaller than the onlink MTU, a good example being a PPPoE 1492 MTU on a ADSL link. The router could annouce the other link's MTU as the offlink-MTU (assuming it is smaller than the LAN interface's MTU), which could avoid a PMTUD cycle for every new offlink connection that encounters the smaller 2nd hop MTU. If there aren't any big holes in what I'm suggesting, I'm willing to spend some time co-authoring an Internet draft on this. Thanks, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 02:27:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvqzx-0007pN-0P; Fri, 22 Jul 2005 02:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvqzu-0007pI-NL for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 02:27:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16460 for ; Fri, 22 Jul 2005 02:27:01 -0400 (EDT) Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvrU6-0005Di-8L for ipv6@ietf.org; Fri, 22 Jul 2005 02:58:14 -0400 Received: from S018431 ([141.154.39.164]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IK0004QXN8ZIBE1@vms046.mailsrvcs.net> for ipv6@ietf.org; Fri, 22 Jul 2005 01:27:01 -0500 (CDT) Date: Fri, 22 Jul 2005 02:26:59 -0400 From: "timothy enos" To: "'IPv6 WG'" Message-id: <001701c58e86$5e1937c0$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.2 (+) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Subject: RFC 3484 update? X-BeenThere: ipv6@ietf.org 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="===============0568344285==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0568344285== Content-type: multipart/alternative; boundary="----=_NextPart_000_0018_01C58E64.D70797C0" This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C58E64.D70797C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit On 23Jun05, on this list there began and ended a thread concerning ULAs, multicast, and RFC 3484. I agree with the contention espoused by some that RFC 3484 should be updated. Section 3.1 clearly states that with the presence of a multicast destination address, a comparison between the multicast address scope and that of the unicast is required. Not only is there comparison, but also mapping. This 1:1 correspondence is problematic for site-local (and presumably organization-local) multicast addresses given RFC 3879 which formally deprecated unicast site-local addresses (FEC0::/10). To what type of unicast source address will the algorithm map site-local (0x5) and organization-local (0x8) now that unicast site-locals are deprecated? The last sentence in RFC 3484, page 7, section 3.1 says: "This mapping implicitly conflates unicast site boundaries and multicast site boundaries." This part of the source address selection algorithm is fundamentally broken (for 'new' implementations) given RFC 3879. Similarly broken would be the part of the destination address selection algorithm that assigns a site-local scope to the RFC 1918 addresses. Another reason for the update of RFC 3484 would seem to be that RFC 2373, 2462, 3041 (all normative references for 3484) are in the process of being updated themselves (with the very first one listed, "IP Version 6 Addressing Architecture" being in its second revision since RFC 3484 was published (the first of course being RFC 3513)). Will RFC 3484 be updated? If 'yes', when? If not, why not? Best regards, Tim Enos 1Sam16:7 ------=_NextPart_000_0018_01C58E64.D70797C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RFC 3484 update?

On = 23Jun05, on this = list there began and ended a thread concerning ULAs, multicast, and RFC = 3484. = I agree with the contention espoused by = some that RFC 3484 should be updated. Section 3.1 clearly states that with the presence of a = multicast destination address, a comparison between the multicast = address scope and that of the unicast is required. Not only is there comparison, but also mapping. This 1:1 = correspondence is problematic for site-local (and presumably = organization-local) multicast addresses given RFC 3879 which formally deprecated unicast = site-local addresses (FEC0::/10). To what type of unicast = source address will the algorithm map site-local (0x5) and organization-local = (0x8) = now that unicast site-locals = are deprecated? The last sentence in RFC 3484, page 7, section 3.1 = says: = “This mapping implicitly conflates unicast site boundaries = and multicast site = boundaries.” This part of the source address selection = algorithm = is fundamentally broken = (for = ‘new’ implementations) given RFC 3879. Similarly broken would be the part of the destination = address selection algorithm that assigns a site-local scope to the RFC 1918 = addresses.

Another reason for the update of RFC 3484 would seem to = be that = RFC 2373, 2462, 3041 (all normative = references for = 3484) = are in the process of being updated = themselves (with the very first one listed, “IP Version 6 Addressing = Architecture” being in its second revision since RFC 3484 was = published (the first of course being RFC 3513)).

Will = RFC 3484 be updated? If ‘yes’, when? = If not, why not?

Best = regards,

Tim = Enos

1Sam16:7

------=_NextPart_000_0018_01C58E64.D70797C0-- --===============0568344285== 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 -------------------------------------------------------------------- --===============0568344285==-- From ipv6-bounces@ietf.org Fri Jul 22 05:41:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvu24-0007vb-LC; Fri, 22 Jul 2005 05:41:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvu22-0007vQ-EN for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 05:41:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26521 for ; Fri, 22 Jul 2005 05:41:23 -0400 (EDT) Received: from smta03.mail.ozemail.net ([203.103.165.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvuWF-0004fa-9I for ipv6@ietf.org; Fri, 22 Jul 2005 06:12:40 -0400 Received: from ubu.nosense.org ([210.84.224.184]) by smta03.mail.ozemail.net with ESMTP id <20050722094114.RXIG24950.smta03.mail.ozemail.net@ubu.nosense.org>; Fri, 22 Jul 2005 09:41:14 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 848F162AAE; Fri, 22 Jul 2005 19:11:13 +0930 (CST) Date: Fri, 22 Jul 2005 19:11:13 +0930 From: Mark Smith To: Mark Smith Message-Id: <20050722191113.3f001b84.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; 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.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: iljitsch@muada.com, ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Fri, 22 Jul 2005 15:09:42 +0930 Mark Smith wrote: > On Fri, 22 Jul 2005 14:20:37 +0930 > Mark Smith wrote: > > > Hi, > > > > On Fri, 22 Jul 2005 10:32:48 +0900 (JST) > > Ryota Hirose wrote: > > > > > Hi, > > > > > > >From: Iljitsch van Beijnum > > > >Date: Thu, 21 Jul 2005 10:19:56 +0200 > > > > > > > > > > > > Yes, your idea is a realistic, and also equal to almost current > > > implementations, I think. > > > > > > BTW, suppose following netowrk. > > > > > > Internet > > > | > > > ROUTER > > > | > > > | 100BASE-TX / MTU=1500 > > > | > > > GbE-SWITCH > > > | | > > > | | 1000BASE-T / MTU=9018 > > > | | > > > HOST1 HOST2 > > > > > > HOST1, HOST2 and GbE-SWITCH support 1000BASE-T and Jumbo Frames, but > > > ROUTER has only 100BASE-TX interfaces and doesn't support Jumbo > > > Frames. In this network, ROUTER will send RA. If the MTU option, > > > which value is 1500, is included in RA, HOST1 and HOST2 will accept > > > it, and are disabled Jumbo Frames. So, if we want to use Jumbo > > > Frambes between HOSTs, (1) HOSTs must neglect MTU option, (2) ROUTER > > > must send RA without MTU option, (3) or ROUTER must send RA with MTU > > > option which value is 9018, illegal MTU for ROUTER itself. > > > > > > (2) RA without MTU option is always valid. But (1) neglect MTU > > > option, or (3) MTU option with illegal value for sender itself, are > > > acceptable? > > > > > > > I'd think not, probably in either (1) or (3), as an interface MTU value > > implies that the other devices attached to the same segment / link can > > also receive (and process) the MTU sized frames. > > > > To support differing MTU values on a single link/segment, each node > > would have to somehow keep track of the Maximum Receive Unit value of > > its link/segment neighbours. PPP supports doing this, and is able to do > > it because a level of layer 2 parameter negotiation goes on before the > > link is brought up. It is also simple to do because there is only one > > neighbour. > > > > For this sort of thing to be supported on a multi-access media, such as > > an ethernet, I'd think some sort of similar, per neighbour, layer 2 > > parameter negotiation of discovery protocol would have to be developed. > > > > Thinking about this a bit more, this could probably be fairly easy to > achieve by creating a "onlink-MRU" or "interface-MRU" option for ND > Neighbour Advertisements. There'd need to be some logic in how a sending > node selects the size of the packets that it sends to a neighbour, based > on comparing the values of its own local interface MTU, the link's MTU > as announced in the RA(s) and the target neighbours announced > onlink-MRU, if it announces one. > Looks like this might not be possible, as according to RFC2461, " variable MTU - Neighbor Discovery allows routers to specify a MTU for the link, which all nodes then use. All nodes on a link must use the same MTU (or Maximum Receive Unit) in order for multicast to work properly. Otherwise when multicasting a sender, which can not know which nodes will receive the packet, could not determine a minimum packet size all receivers can process." Certainly understandable, a shame though. I can see more and more SOHO users buying GigE because it is getting cheap, yet being hobbled to 1.5K frames because their broadband router doesn't have a GigE interface supporting jumbo frames. Hopefully SOHO broadband routers start using GigE jumbo frame capable interfaces, just because they'll be cheap. Maybe the media default or the RA announced MTU could be used for multicast traffic, where as a ND discovered best value MRU between specific neighbours could be used for unicast traffic between them. > > A ND RA option, indicating the "router-MRU" or "offlink-MTU" value might > be necessary and useful also. > > Necessary if nodes don't issue ND NSes for routers if they have already > learnt the router's Link layer address via the RA. It may also be useful to > have an onlink-MRU option as well, to allow for local traffic targetted > at the router's onlink interface address(es), which may be used for > administrative access to the router, although probably not necessary for > the amount of onlink traffic a router receives. > > Useful if the router only has one other link, e.g., a link to the > Internet, and the MTU of that link is smaller than the onlink MTU, a > good example being a PPPoE 1492 MTU on a ADSL link. The router could > annouce the other link's MTU as the offlink-MTU (assuming it is smaller than the > LAN interface's MTU), which could avoid a PMTUD cycle for every new > offlink connection that encounters the smaller 2nd hop MTU. > If different MTUs were able to be used for multicast and unicast traffic, then I think the above could also work out. 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 Fri Jul 22 07:42:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvvv8-00034t-6y; Fri, 22 Jul 2005 07:42:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvvv5-00032G-8M for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 07:42:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04468 for ; Fri, 22 Jul 2005 07:42:21 -0400 (EDT) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvwPI-0001Hq-Ck for ipv6@ietf.org; Fri, 22 Jul 2005 08:13:37 -0400 Received: OTM-MO id j6MBg6Sr007289; Fri, 22 Jul 2005 20:42:06 +0900 (JST) Received: OTM-MIX0 id j6MBg5LB011144; Fri, 22 Jul 2005 20:42:05 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j6MBg5u5005239; Fri, 22 Jul 2005 20:42:05 +0900 (JST) Date: Fri, 22 Jul 2005 20:42:05 +0900 (JST) Message-Id: <20050722.204205.63767071.keiichi@iijlab.net> To: Samita.Chakrabarti@eng.sun.com From: Keiichi SHIMA In-Reply-To: <200507212053.j6LKr41L952097@jurassic.eng.sun.com> References: <200507212053.j6LKr41L952097@jurassic.eng.sun.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: julien.laganier@sun.com, erik.nordmark@sun.com, ipv6@ietf.org Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello Samita, I have one question about the usage of IPV6_PREFER_DST_LARGESCOPE and IPV6_PREFER_DST_SMALLSCOPE socket options. I'm afraid I cannot imagine when I need to use the above socket options, since selection of a destination address is done by getaddrinfo() (or by specifying an address explicitly) I think. Do you have any concrete idea of the usage of above socket options? --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 08:09:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvwKy-000890-Ih; Fri, 22 Jul 2005 08:09:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvh9J-0003qW-Q0 for ipv6@megatron.ietf.org; Thu, 21 Jul 2005 15:56:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05238 for ; Thu, 21 Jul 2005 15:56:03 -0400 (EDT) Received: from pony1pub.arc.nasa.gov ([128.102.31.41] helo=arc.nasa.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvhdM-0001ER-6M for ipv6@ietf.org; Thu, 21 Jul 2005 16:27:11 -0400 Received: from [129.99.139.64] ([129.99.139.64] verified) by pony1pub.arc.nasa.gov (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 20348696 for ipv6@ietf.org; Thu, 21 Jul 2005 12:55:47 -0700 Message-ID: <42DFFDBB.4010404@nasa.gov> Date: Thu, 21 Jul 2005 12:55:39 -0700 From: Hugh LaMaster User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org References: <20050720.183754.22498937.hirose@comm.yamaha.co.jp> <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 22 Jul 2005 08:09:06 -0400 Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hugh LaMaster List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The author of the RFC has clarified (personal communication, posted with permission) that the intention was never to prohibit jumbo frames, but rather: It is only supposed to mean that Router Advertisements cannot increase the MTU above whatever it was otherwise believed to be, and that in the absence of configuration information (including DHCP), it is presumed to be 1500. "Please include the admission that perhaps it could have been clearer. Remember the old "We'll fix it in Draft" mantra that used to be the ipngwg refrain?" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 11:00:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvz1F-00066e-0E; Fri, 22 Jul 2005 11:00:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvz1D-00066Z-2D for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 11:00:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22537 for ; Fri, 22 Jul 2005 11:00:51 -0400 (EDT) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvzVR-0000eN-A7 for ipv6@ietf.org; Fri, 22 Jul 2005 11:32:11 -0400 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by palrel13.hp.com (Postfix) with ESMTP id CEC151C0027C; Thu, 28 Jul 2005 10:58:03 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id CE5FF8A0; Fri, 22 Jul 2005 08:00:39 -0700 (PDT) Received: from [16.116.104.135] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j6MF0dd0001445747; Fri, 22 Jul 2005 11:00:39 -0400 (EDT) Message-ID: <42E10A17.7000306@hp.com> Date: Fri, 22 Jul 2005 11:00:39 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti References: <200507212053.j6LKr41L952097@jurassic.eng.sun.com> In-Reply-To: <200507212053.j6LKr41L952097@jurassic.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: julien.laganier@sun.com, erik.nordmark@sun.com, ipv6@ietf.org Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>Overall comment: >> >>1. The draft talks about setting flag X and flag not-X, but the only >>place I see where this can happen is trying to set these together: >> >> IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA >> AI_PREFER_SRC_CGA | AI_PREFER_SRC_NONCGA >> >>Am I missing something? Can I somehow turn-off the use of Care-of >>Addresses as source addresses? Maybe it's implied that if I don't set >>the flag in the setsockopt()/getaddrinfo() call that it turns-off using >>that type of source address? >> >>------------------------------------------------------------------------ > > > The combination of flag X and not-X is not allowed - only one should be > set at one time, becuase one packet has one source address. After talking to Vlad I now understand this, you're saying these are invalid flags to set together: HOME | COA TMP | PUBLIC CGA | NONCGA LARGE | SMALL From a C-code perspective, flag X and not-X would mean: HOME & ~HOME So I don't like the X/not-X text, I like the wording of "conflicting flags" much better as used in a few other places. Maybe if the end of Section 4 could say this: Setting conflicting flags at the same time results in the error EINVAL. For example, invalid combinations of flags are: IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA IPV6_PREFER_SRC_TMP | IPV6_PREFER_SRC_PUBLIC IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA IPV6_PREFER_SRC_LARGESCOPE | IPV6_PREFER_SRC_SMALLSCOPE If flags are set as a combination of 'X' and 'Y', and if 'Y' is not applicable or available in the system, then the selected address has attribute 'X' and system default for the attribute 'Y'. For example, a possible valid combination of flags can be: IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_LARGESCOPE There are other places that would need updating too. > The default flags are described in section 7. For example, by default > *_SRC_HOME is the choice of flag, ( it means COA address is not used > by default as source address), but one can change that by using setsockopt() > with *_SRC_COA. The default is to follow RFC 3484, right? :) >> IPv4-mapped IPv6 addresses, which are IPv4 addresses in a form that >> can be used on an AF_INET6 socket, are supported in this API. In >> some cases the IPv4-mapped addresses may not make much sense because >> the attributes are IPv6 specific. For example, IPv6 temporary >> addresses are not the same as private IPv4 addresses. However, the >> IPv4 mapped-address support may be useful for mobile home address and >> care-of-address. At this point it is not understood whether this API >> has any value to IPv4 addresses or AF_INET family of sockets. >> >>The second to last sentence here is confusing (regarding mobile), can >>you explain what you meant? > > > It was discussed in the ipv6 list sometimes ago that IPV4-mapped IPv6 > addresses may be useful for home-address and COA for IPv4 > and IPV6 interoperability. It is not well understood, but I think it > is possible that a MIPv4 compliant dual-stack node may want to comunicate with a > IPv6 address. Ok, then can this sentence be changed to give that information: "However, the IPv4 mapped-address support may be useful for mobile home address and care-of-address." Thanks, -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 Jul 22 14:40:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2Rd-00076e-Ri; Fri, 22 Jul 2005 14:40:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2Rb-00076W-N2 for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 14:40:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09098 for ; Fri, 22 Jul 2005 14:40:21 -0400 (EDT) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw2vt-0000jE-TF for ipv6@ietf.org; Fri, 22 Jul 2005 15:11:42 -0400 Received: from dax (ip178.post-vineyard.dfw.ygnition.net [66.135.181.178]) by ns2.sea (8.13.4/8.12.5) with SMTP id j6MIe3Qv031758; Fri, 22 Jul 2005 11:40:03 -0700 Message-ID: <017901c58eec$cbf479b0$6701a8c0@dax> From: "Stephen Sprunk" To: "Mark Smith" References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> Date: Fri, 22 Jul 2005 13:20:40 -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.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: iljitsch@muada.com, ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thus spake "Mark Smith" > Thinking about this a bit more, this could probably be fairly easy to > achieve by creating a "onlink-MRU" or "interface-MRU" option for ND > Neighbour Advertisements. There'd need to be some logic in how a > sending node selects the size of the packets that it sends to a > neighbour, based on comparing the values of its own local interface > MTU, the link's MTU as announced in the RA(s) and the target > neighbours announced onlink-MRU, if it announces one. ... > If there aren't any big holes in what I'm suggesting, I'm willing to > spend some time co-authoring an Internet draft on this. The hole is that there may be an L2 device in the middle which has a lower MTU than the end hosts. The neighbor MTU is an upper bound, but it's not guaranteed to work -- you need to probe to see what really works. Just like PMTUD, you need to periodically probe and adjust to changing network conditions, including detecting "black holes". Fred Baker suggested the host send both minimum MTU (576 for v4 and 1280 for v6) and maximum MTU frames in a given burst and track what gets through. Obviously if the larger frames work you go with that, but if not you need to ratchet the max MTU down until things work (while using the min MTU so the session doesn't stall). The most perverse scenario I can envision is a network where one host has an MTU of 9k, another has 8k, one network path has 10k, another path has 3k, and the path varies every few minutes (and isn't necessarily symmetric). Obviously it needs to be stated that MTU changes need to be communicated up to TCP for MSS adjustments -- darn layer violations. One thing we probably need to decide is if it's "correct" for the above hosts to (a) fall back to 1500, (b) use 3k all the time, or (c) alternate between 3k and 8k. I'm leaning towards all three being legal with a recommendation for the second option 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 Fri Jul 22 15:04:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2oY-0000Xg-Qd; Fri, 22 Jul 2005 15:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2oV-0000PW-7o for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 15:04:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10850 for ; Fri, 22 Jul 2005 15:04:01 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw3In-0001fg-KN for ipv6@ietf.org; Fri, 22 Jul 2005 15:35:21 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 22 Jul 2005 12:03:54 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6MJ3p6p005433; Fri, 22 Jul 2005 12:03:51 -0700 (PDT) Received: from [10.32.244.219] (stealth-10-32-244-219.cisco.com [10.32.244.219]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j6MJ1u0j010540; Fri, 22 Jul 2005 12:01:56 -0700 In-Reply-To: <017901c58eec$cbf479b0$6701a8c0@dax> References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> Mime-Version: 1.0 (Apple Message framework v733) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1CB1332A-EDE8-4C6B-8379-B52AED08DEFF@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 22 Jul 2005 12:03:48 -0700 To: "Stephen Sprunk" X-Mailer: Apple Mail (2.733) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1122058916.817517"; x:"432200"; a:"rsa-sha1"; b:"nofws:1150"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"pHKRPUUgSJy8iItd7oprg7tLZkgcgCf+iRctiRQA9tk1IuOYae2XSAlWXh/3PsNd1qvCOJts" "/nypXZ0EADw86avH3q7InC/S1PH37W5b6H7kW7oIS0zK5kAEkR/kOK8dZMG6L52nMegRL1xqjRi" "ZR61FrMHsLY+kxsBeVTNVv78="; c:"From: Fred Baker "; c:"Subject: Re: jumbo frame of GbE and IPv6"; c:"Date: Fri, 22 Jul 2005 12:03:48 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Actually, I should think 1280 would be fine for both. The issue tends to be IPSEC tunnel mode and other tunneling implementations in the path in between, otherwise I would say "ip data size == 1500". 576 byte frames are a leftover from ARPANET IMPs and Fuzzballs... The suggestion actually comes from Matt's document, I just pointed it out and suggested a simple first-burst implementation. http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-04.txt "Path MTU Discovery", Matt Mathis, 22-Feb-05 In context, Max MTU is the max on the local interface. If you're on a 10/100 Ethernet and you're in an end station, you probably don't do 9K byte MTUs, while on a GigE interface you probably do. Depending on the implementation, you might try to send an 8192 byte ip datagram no matter what and it might not get out of your system, or you may be able to read the MTU size. On Jul 22, 2005, at 11:20 AM, Stephen Sprunk wrote: > Just like PMTUD, you need to periodically probe and adjust to > changing network conditions, including detecting "black holes". > Fred Baker suggested the host send both minimum MTU (576 for v4 and > 1280 for v6) and maximum MTU frames in a given burst and track what > gets through. Obviously if the larger frames work you go with > that, but if not you need to ratchet the max MTU down until things > work (while using the min MTU so the session doesn't stall). > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 15:14:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2yo-0005Fo-Vy; Fri, 22 Jul 2005 15:14:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2yl-0005Ff-GP for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 15:14:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12350 for ; Fri, 22 Jul 2005 15:14:37 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw3T3-000260-0K for ipv6@ietf.org; Fri, 22 Jul 2005 15:45:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Jul 2005 15:14:30 -0400 Message-ID: Thread-Topic: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.txt Thread-Index: AcWOz1jh7Zn9PVEmT1yzz+vtc0vr0QAIWxcQ From: "Steve Cipolli" To: "Samita Chakrabarti" , X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The third sentence in the abstract appears to be broken: This document fills that gap by specifying socket level options add new flags for the getaddrinfo() API to specify preferences for address selection that modify the default address selection algorithm. I think what was intended was: This document fills that gap by specifying socket level options and adding new flags for the getaddrinfo() API to specify preferences for address selection that modify the default address selection algorithm. --Stephen -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 16:20:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw40c-0005EP-Ce; Fri, 22 Jul 2005 16:20:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw40a-0005EK-SG for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 16:20:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23585 for ; Fri, 22 Jul 2005 16:20:34 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw4Uq-0006ko-RN for ipv6@ietf.org; Fri, 22 Jul 2005 16:51:56 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6MJlw106961; Fri, 22 Jul 2005 12:47:58 -0700 X-mProtect: <200507221947> Nokia Silicon Valley Messaging Protection Received: from danira-pool048138.americas.nokia.com (10.241.48.138, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdxD0rth; Fri, 22 Jul 2005 12:47:57 PDT Message-Id: <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 22 Jul 2005 13:18:24 -0700 To: Ryota Hirose From: Bob Hinden In-Reply-To: <20050722.103248.35008368.hirose@comm.yamaha.co.jp> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: iljitsch@muada.com, ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, >BTW, suppose following netowrk. > > Internet > | > ROUTER > | > | 100BASE-TX / MTU=1500 > | > GbE-SWITCH > | | > | | 1000BASE-T / MTU=9018 > | | > HOST1 HOST2 > >HOST1, HOST2 and GbE-SWITCH support 1000BASE-T and Jumbo Frames, but >ROUTER has only 100BASE-TX interfaces and doesn't support Jumbo >Frames. In my personal view, having devices on shared media with different MTU's is just a bad idea. Trying to get it to work is complicated and I think it will have lots of nasty failure cases. If one wants to have mixed speeds (like the example above) then use the default MTU (i.e., 1500) or replace the GbE-Switch with a Router. If one wants Jumbo Frames, then make sure all of the nodes on the link support 1000Base-T. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 17:01:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4dg-0006Zu-6e; Fri, 22 Jul 2005 17:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4dc-0006QH-AB for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 17:00:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26546 for ; Fri, 22 Jul 2005 17:00:53 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw57t-0008HW-9G for ipv6@ietf.org; Fri, 22 Jul 2005 17:32:15 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 22 Jul 2005 14:00:44 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6ML0gJL006734; Fri, 22 Jul 2005 14:00:42 -0700 (PDT) Received: from [10.32.244.219] (stealth-10-32-244-219.cisco.com [10.32.244.219]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j6MKwmQo011528; Fri, 22 Jul 2005 13:58:48 -0700 In-Reply-To: <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96750F15-9FDA-4751-909E-66EB4BAEC002@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 22 Jul 2005 14:00:40 -0700 To: Bob Hinden X-Mailer: Apple Mail (2.733) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1122065928.796150"; x:"432200"; a:"rsa-sha1"; b:"nofws:1345"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"AnptLKnfXzmKWIXK2DzTHuGZoi0OpJ/0XyA4YWGYD45aqfTKTobuYhT43zC+fd/fW7Vg28vu" "g46u9IWXiiyvYsF6mcXP7wC/a+3NEfgK7fZZsfqOFIrt7iLigad4StE1As87Y0vSYP4AdDDIdid" "insyMWm8MiqtvLrpknE1qghg="; c:"From: Fred Baker "; c:"Subject: Re: jumbo frame of GbE and IPv6"; c:"Date: Fri, 22 Jul 2005 14:00:40 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: iljitsch@muada.com, ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In my personal view, networks like this are a fact of life. One frequently is handed things by disparate people with disparate budgets, responsibilities, and requirements. For example, perhaps IT provides the switch, the router is what the managed-service ISP installed several years ago and still works, and the servers are what the department bought for this nifty-keeno application they're in the process of installing. Hence, path MTU is a question of what's on the path for a session, not something else. On Jul 22, 2005, at 1:18 PM, Bob Hinden wrote: > Hi, > > >> BTW, suppose following netowrk. >> >> Internet >> | >> ROUTER >> | >> | 100BASE-TX / MTU=1500 >> | >> GbE-SWITCH >> | | >> | | 1000BASE-T / MTU=9018 >> | | >> HOST1 HOST2 >> >> HOST1, HOST2 and GbE-SWITCH support 1000BASE-T and Jumbo Frames, but >> ROUTER has only 100BASE-TX interfaces and doesn't support Jumbo >> Frames. >> > > In my personal view, having devices on shared media with different > MTU's is just a bad idea. Trying to get it to work is complicated > and I think it will have lots of nasty failure cases. If one wants > to have mixed speeds (like the example above) then use the default > MTU (i.e., 1500) or replace the GbE-Switch with a Router. If one > wants Jumbo Frames, then make sure all of the nodes on the link > support 1000Base-T. > > 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 ipv6-bounces@ietf.org Fri Jul 22 17:10:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4mP-0004SB-Tz; Fri, 22 Jul 2005 17:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4mM-0004R7-4e for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 17:09:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27298 for ; Fri, 22 Jul 2005 17:09:55 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw5Ge-0000Bc-BS for ipv6@ietf.org; Fri, 22 Jul 2005 17:41:17 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j6ML9gYR164948 for ; Fri, 22 Jul 2005 21:09:42 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6ML9gO1128374 for ; Fri, 22 Jul 2005 23:09:42 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j6ML9g05031228 for ; Fri, 22 Jul 2005 23:09:42 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j6ML9fOM031225; Fri, 22 Jul 2005 23:09:41 +0200 Received: from zurich.ibm.com (sig-9-145-254-94.de.ibm.com [9.145.254.94]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA31696; Fri, 22 Jul 2005 23:09:39 +0200 Message-ID: <42E1608E.3060708@zurich.ibm.com> Date: Fri, 22 Jul 2005 23:09:34 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Manfredi, Albert E" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, global-v6@lists.apnic.net Subject: Re: [GLOBAL-V6] Re:I-DACTION:draft-narten-ipv6-3177bis-48boundary-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Manfredi, Albert E wrote: > Not necessarily lots of funky services. > > Here's the sequence that leads to this interface ID length question. > > 1. RFC 2373, the precursor of RFC 3513, introduces 64-bit IIDs. Okay, > seems logical. (Also reminiscent of NSAPA structure from back in ION wg > days.) > > 2. RFC 3513 strengthens that, suggesting that the IANA assign only > globally unique addresses starting in binary 001, which means by > extension that these will only have 64-bit IIDs. Okay, fair enough. > > 3. RFC 3177 suggests that every site be assigned a /48 prefix at least. > > 4. I-D 3177-bis introduces the idea that wanton waste is perhaps not a > good idea, and /56 prefixes would be a better idea than default /48 > prefixes. > > 5. RFC 3041 says maybe those globally unique IIDs create a problem > anyway. > > I come to some conclusions from this. > > First, if 64-bit IIDs create security problems, then one possible remedy > is not to insist that all IANA assignments must use 64-bit IIDs. > > Second, that if all IANA assignments do not have to consist of 64-bit > IIDs, the concerns of I-D 3177-bis are also alleviated. > > Third, that the underlying model on which RFCs 3513 and 3177 are based > seems to be heavily biased to assignment of IP addresses from ISPs to > businesses and residences, client-server architectures, and address > autoconfiguration. But perhaps that's not going to be where the future > leads, for the vast majority of IPv6 devices and applications. Perhaps > we're looking at bewildering arrays of devices (sensors and actuators) > embedded in all manner of sites, including mobile platforms, roadways, > in individual home systems, where globally unique IIDs are not > appropriate and where very large numbers of relatively small IP subnets > are instead the norm. > > So yes, this is a different discussion perhaps, but not unrelated. It > says, why are we following just this one path? Because /64 isn't some theoretical construct that's easy to change. It's built into innumerable specifications. It's shipped product. And it isn't a significant problem, as far as I can see from draft-narten-iana-rir-ipv6-considerations-00.txt /48 *is* a problem, and seems quite easy to fix. 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 Jul 22 18:40:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw6CO-0000ji-2t; Fri, 22 Jul 2005 18:40:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw6CM-0000jd-7S for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 18:40:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08286 for ; Fri, 22 Jul 2005 18:40:50 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw6gf-0004P5-DB for ipv6@ietf.org; Fri, 22 Jul 2005 19:12:14 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6MM8kW31615 for ; Fri, 22 Jul 2005 15:08:46 -0700 X-mProtect: <200507222208> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019069067.americas.nokia.com (172.19.69.67, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdSygsvs; Fri, 22 Jul 2005 15:08:44 PDT Message-Id: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 22 Jul 2005 15:40:27 -0700 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Here is the first cut at an agenda for the IPv6 working group session at the Paris IETF. Please review and send us comments, deletions, and additions. Thanks, Bob Hinden & Brian Haberman IPv6 Chairs Internet Protocol Version 6 WG (IPv6) Tuesday, August 2, 2005 1400-1600 Afternoon Session I -------------------------------------- Introduction, Call for Scribes, Hinden 05 minutes and Agenda Bashing Document Status Haberman 05 minutes IPv6 Node Information Queries Haberman 10 minutes Goal: Close open issues draft-ietf-ipngwg-icmp-name-lookups-12.txt IPv6 Address Allocation to End Sites Narten 20 minutes Goal: Discussion draft-narten-ipv6-3177bis-48boundary-00.txt IPv6 over IEEE802.16 Kim 10 minutes Goal: New draft, Initial Discussion draft-jin-ipv6-over-ieee802.16-00.txt URI Syntax Fenner 15 minutes Goal: Make decision to adopt proposal draft-fenner-literal-zone-01.txt Implementation Reports for Haberman 10 minutes Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Goal: Call for reports Next Steps for IPv6 w.g. Hinden 15 minutes Advancing core specification to Standard Goal: Discussion -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 20:19:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7js-0003G0-Ba; Fri, 22 Jul 2005 20:19:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7jo-0003EO-PC for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 20:19:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13222 for ; Fri, 22 Jul 2005 20:19:28 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw8Dz-0007NT-LK for ipv6@ietf.org; Fri, 22 Jul 2005 20:50:49 -0400 Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6N0JJcn025624; Fri, 22 Jul 2005 17:19:20 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j6N0JJMx741705; Fri, 22 Jul 2005 17:19:19 -0700 (PDT) Message-Id: <200507230019.j6N0JJMx741705@jurassic.eng.sun.com> Date: Fri, 22 Jul 2005 17:18:20 -0700 (PDT) From: Samita Chakrabarti To: keiichi@iijlab.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YzLtTx+Qor8bfm+TMS96GA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: erik.nordmark@sun.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Keiichi, NOTE : [ Julien's address change: julien.ietf@laposte.net ] > > I have one question about the usage of IPV6_PREFER_DST_LARGESCOPE and > IPV6_PREFER_DST_SMALLSCOPE socket options. > > I'm afraid I cannot imagine when I need to use the above socket > options, since selection of a destination address is done by > getaddrinfo() (or by specifying an address explicitly) I think. > > Do you have any concrete idea of the usage of above socket options? The idea is to use both IPV6_PREFER flags in conjunction with corresponding AI_PREFER_* flags in getaddrinfo(). RFC3484 Destination address selection rule #8 ( prefer smaller scope): Thus, IPV6_PREFER_DST_SMALLSCOPE is the default setting for a system. One example might be that if sender wants to use global destination address to talk to an onlink node for which it knows a smaller scope address. In that situation, setting LARGESCOPE socket option and passing AI flag to getaddrinfo() is recommended. Now, for DST flags, it may be possible to get away with AI_PREFER_* flags, but, implementations may vary in implementing getaddrinfo() for collecting potential source addresses (RFC3484 section 8). Hence for portability and consistency reason, both setsockopt() and AI flags are recommended for destination scope. >From implementation point of view do you think IPV6_PREFER_DST_*SCOPE is redundant across all systems ? Thanks, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 20:22:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7mz-0003uH-WF; Fri, 22 Jul 2005 20:22:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7my-0003u1-7W for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 20:22:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13447 for ; Fri, 22 Jul 2005 20:22:46 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw8HH-0007VK-CM for ipv6@ietf.org; Fri, 22 Jul 2005 20:54:09 -0400 Received: from jurassic.eng.sun.com ([129.146.226.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6N0Mdr3024793; Fri, 22 Jul 2005 18:22:40 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j6N0MdBx743614; Fri, 22 Jul 2005 17:22:39 -0700 (PDT) Message-Id: <200507230022.j6N0MdBx743614@jurassic.eng.sun.com> Date: Fri, 22 Jul 2005 17:21:40 -0700 (PDT) From: Samita Chakrabarti To: brian.haley@hp.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Y1N6C4LbdT6nc0tZauVgBw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: erik.nordmark@sun.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > > > > The combination of flag X and not-X is not allowed - only one should be > > set at one time, becuase one packet has one source address. > > After talking to Vlad I now understand this, you're saying these are > invalid flags to set together: > > HOME | COA > TMP | PUBLIC > CGA | NONCGA > LARGE | SMALL > > From a C-code perspective, flag X and not-X would mean: > > HOME & ~HOME > > So I don't like the X/not-X text, I like the wording of "conflicting > flags" much better as used in a few other places. Maybe if the end of > Section 4 could say this: > > Setting conflicting flags at the same time results in the error > EINVAL. For example, invalid combinations of flags are: > > IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA > IPV6_PREFER_SRC_TMP | IPV6_PREFER_SRC_PUBLIC > IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA > IPV6_PREFER_SRC_LARGESCOPE | IPV6_PREFER_SRC_SMALLSCOPE > > If flags are set as a combination of 'X' and 'Y', and if 'Y' > is not applicable or available in the system, then the selected > address has attribute 'X' and system default for the attribute 'Y'. > For example, a possible valid combination of flags can be: > > IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_LARGESCOPE > > There are other places that would need updating too. Point taken. > > The default flags are described in section 7. For example, by default > > *_SRC_HOME is the choice of flag, ( it means COA address is not used > > by default as source address), but one can change that by using setsockopt() > > with *_SRC_COA. > > The default is to follow RFC 3484, right? :) Yes. > > >> IPv4-mapped IPv6 addresses, which are IPv4 addresses in a form that > >> can be used on an AF_INET6 socket, are supported in this API. In > >> some cases the IPv4-mapped addresses may not make much sense because > >> the attributes are IPv6 specific. For example, IPv6 temporary > >> addresses are not the same as private IPv4 addresses. However, the > >> IPv4 mapped-address support may be useful for mobile home address and > >> care-of-address. At this point it is not understood whether this API > >> has any value to IPv4 addresses or AF_INET family of sockets. > >> > >>The second to last sentence here is confusing (regarding mobile), can > >>you explain what you meant? > > > > > > It was discussed in the ipv6 list sometimes ago that IPV4-mapped IPv6 > > addresses may be useful for home-address and COA for IPv4 > > and IPV6 interoperability. It is not well understood, but I think it > > is possible that a MIPv4 compliant dual-stack node may want to comunicate with a > > IPv6 address. > > Ok, then can this sentence be changed to give that information: > > "However, the IPv4 mapped-address support may be useful for mobile home > address and care-of-address." Ok. Thanks, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 20:28:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7sL-0006I3-G4; Fri, 22 Jul 2005 20:28:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7sI-0006HA-Ig for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 20:28:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13857 for ; Fri, 22 Jul 2005 20:28:16 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw8Mc-0007hl-Oj for ipv6@ietf.org; Fri, 22 Jul 2005 20:59:40 -0400 Received: from jurassic.eng.sun.com ([129.146.226.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6N0SFvU001495; Fri, 22 Jul 2005 18:28:16 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j6N0SFnK745159; Fri, 22 Jul 2005 17:28:15 -0700 (PDT) Message-Id: <200507230028.j6N0SFnK745159@jurassic.eng.sun.com> Date: Fri, 22 Jul 2005 17:27:16 -0700 (PDT) From: Samita Chakrabarti To: SCipolli@radvision.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VrY/8AK09QG5+G7Rp0sjyQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: erik.nordmark@sun.com, ipv6@ietf.org Subject: RE: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > The third sentence in the abstract appears to be broken: > > This document fills that gap by specifying socket level options add new > flags for the getaddrinfo() API to specify preferences for address > selection that modify the default > address selection algorithm. > > I think what was intended was: > > This document fills that gap by specifying socket level options and > adding new flags for the getaddrinfo() API to specify preferences for > address selection that modify the default > address selection algorithm. > Agree, the sentence needs change. -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 20:51:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw8Em-0007ZL-89; Fri, 22 Jul 2005 20:51:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw8Ek-0007YV-Cy for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 20:51:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15459 for ; Fri, 22 Jul 2005 20:51:28 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw8j5-0008TV-Pk for ipv6@ietf.org; Fri, 22 Jul 2005 21:22:52 -0400 Received: from [172.16.1.2] (82-192-90-30.leasedsl.net [82.192.90.30]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6N0poRa032874 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 23 Jul 2005 02:51:52 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <017901c58eec$cbf479b0$6701a8c0@dax> References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> Mime-Version: 1.0 (Apple Message framework v733) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> Content-Transfer-Encoding: quoted-printable From: Iljitsch van Beijnum Date: Sat, 23 Jul 2005 02:50:58 +0200 To: Stephen Sprunk X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 22-jul-2005, at 20:20, Stephen Sprunk wrote: >> Thinking about this a bit more, this could probably be fairly easy to >> achieve by creating a "onlink-MRU" or "interface-MRU" option for ND >> Neighbour Advertisements. >> If there aren't any big holes in what I'm suggesting, I'm willing to >> spend some time co-authoring an Internet draft on this. I'm sure we can find a nice restaurant or caf=E9 in Paris to discuss =20 the matter further. :-) > The hole is that there may be an L2 device in the middle which has =20 > a lower MTU than the end hosts. The neighbor MTU is an upper =20 > bound, but it's not guaranteed to work -- you need to probe to see =20 > what really works. (Layer 1 devices can also impose MTU limits.) It's important to keep this simple, unless the IEEE guys also want to =20= play and add mechanisms to exchange MTU information between switches. > Just like PMTUD, you need to periodically probe and adjust to =20 > changing network conditions, including detecting "black holes". =20 > Fred Baker suggested the host send both minimum MTU (576 for v4 and =20= > 1280 for v6) and maximum MTU frames in a given burst and track what =20= > gets through. I'm not really comfortable with this... It makes more sense to me to =20 have a router or two, or maybe one or two non-router hosts, send out =20 "MTU announcements", and other hosts only announce the non-standard =20 MTU in neighbor advertisements when they recently heard one of those =20 announcements. When the MTU suddenly decreasees, the announcements =20 are no longer heard, hosts put 1500 in their neighbor advertisements =20 and neighbor unreachability detection does the rest. The fact that =20 ethernet is supposed to have a tree topology makes things slightly =20 simpler. > The most perverse scenario I can envision is a network where one =20 > host has an MTU of 9k, another has 8k, one network path has 10k, =20 > another path has 3k, and the path varies every few minutes (and =20 > isn't necessarily symmetric). Real-life ethernet isn't supposed to be like that... For those who think there isn't a real problem here: it takes a =20 little over 800 packets per second to saturate a 10 Mbps ethernet =20 link. At GE speeds that's 80000 packets per second. It is very hard =20 to achieve decent performance when you have to stop what you're doing =20= 80000 times per second... There is also the environment to consider =20 because the amount of power switches use is strongly related to the =20 number of packets that flow through the switch. So increasing the MTU =20= from (for instance) 1500 to 9000 bytes means it only takes 3 packets =20 to transfer 18000 bytes (2 data, 1 ack), while it takes (best case) =20 13 packets at 1500 bytes (12 data, 1 ack) but usually 18 (6 acks). =20 That saves a LOT of power. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 20:57:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw8KJ-0001XX-6E; Fri, 22 Jul 2005 20:57:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw8KH-0001U6-Aq for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 20:57:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15846 for ; Fri, 22 Jul 2005 20:57:11 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw8oc-0000E6-Nh for ipv6@ietf.org; Fri, 22 Jul 2005 21:28:35 -0400 Received: from [172.16.1.2] (82-192-90-30.leasedsl.net [82.192.90.30]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6N0vrRa032977 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 23 Jul 2005 02:57:54 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Sat, 23 Jul 2005 02:57:09 +0200 To: Bob Hinden X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 22-jul-2005, at 22:18, Bob Hinden wrote: > In my personal view, having devices on shared media with different > MTU's is just a bad idea. Trying to get it to work is complicated > and I think it will have lots of nasty failure cases. If one wants > to have mixed speeds (like the example above) then use the default > MTU (i.e., 1500) or replace the GbE-Switch with a Router. If one > wants Jumbo Frames, then make sure all of the nodes on the link > support 1000Base-T. Unfortunately 1000baseT (is that the correct designation?) doesn't equal jumboframe capability, so the problem remains. Don't forget that management issues in layer 2 networks (= a single layer 3 subnet) are very different from those on the global internet: most layer 2 networks are managed by a single organization. Since we had the hubris to think we could do PMTUD for the global internet, I think we shouldn't shy away from doing the same thing for layer 2. As always, the operator community will decide wheter what we come up with is usable in practice. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jul 22 23:08:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwANc-0007Zl-9l; Fri, 22 Jul 2005 23:08:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwANX-0007Vs-B5 for ipv6@megatron.ietf.org; Fri, 22 Jul 2005 23:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03842 for ; Fri, 22 Jul 2005 23:08:40 -0400 (EDT) From: fujisaki@syce.net Received: from mail.syce.net ([192.16.178.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwArs-00040o-EA for ipv6@ietf.org; Fri, 22 Jul 2005 23:40:06 -0400 Received: from localhost (mail.syce.net [IPv6:2001:218:4fd::25]) by mail.syce.net (8.12.11/8.12.11) with ESMTP/inet6 id j6N38MLJ054633; Sat, 23 Jul 2005 12:08:22 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Sat, 23 Jul 2005 14:01:10 +0900 (JST) Message-Id: <20050723.140110.115902850.fujisaki@syce.net> To: ipv6@ietf.org In-Reply-To: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> X-Mailer: Mew version 4.2 on XEmacs 21.4.15 (Security Through Obscurity) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Bob, | Here is the first cut at an agenda for the IPv6 working group session at | the Paris IETF. Please review and send us comments, deletions, and additions. Could you please give me a few minutes for following draft? Title: Distributing Default Address Selection Policy using DHCPv6 Filename: draft-fujisaki-dhc-addr-select-opt-00.txt As a result of a discussion at last IETF dhc wg, I need ipv6 wg support to move forward this draft. As I posted before, this draft describes the RFC3484 policy table distribution (please refer http://www.nttv6.net/dass). Yours sincerely, -- Tomohiro Fujisaki -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jul 23 11:12:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwLgN-0001Om-3F; Sat, 23 Jul 2005 11:12:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwLgL-0001Nz-0T for ipv6@megatron.ietf.org; Sat, 23 Jul 2005 11:12:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01676 for ; Sat, 23 Jul 2005 11:12:50 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx3.orcon.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwMAn-0008Il-3t for ipv6@ietf.org; Sat, 23 Jul 2005 11:44:22 -0400 Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx3.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j6NFEh0H030928 for ; Sun, 24 Jul 2005 03:14:46 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1DwLg3-0003OG-00 for ; Sun, 24 Jul 2005 03:12:35 +1200 Message-ID: <42E25E62.2010805@coders.net> Date: Sun, 24 Jul 2005 03:12:34 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050521 X-Accept-Language: en-nz, en MIME-Version: 1.0 CC: IETF IPv6 Mailing List References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> In-Reply-To: <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/988/Sat Jul 23 00:29:55 2005 on dbmail-mx3.orcon.net.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >> The hole is that there may be an L2 device in the middle which has a >> lower MTU than the end hosts. The neighbor MTU is an upper bound, >> but it's not guaranteed to work -- you need to probe to see what >> really works. > > > (Layer 1 devices can also impose MTU limits.) > > It's important to keep this simple, unless the IEEE guys also want to > play and add mechanisms to exchange MTU information between switches. Before two hosts can transmit packets on Ethernet they have to undergo neighbour solicitation to find the remote ends hardware address anyway. When you send the neighbour solicitation you could pad the packet out with multiple "MTU padding" options to make the packet the size of the MTU you want to use. The remote end receives the message, and adds it's own padding[1] to the reply. If the original host receives a message from the remote host with MTU padding options then it knows the remote host can receive a message at least that big and uses that as the remote hosts MTU. If the original host does not receive a reply, it updates it's neighbour cache to say that the MTU supported is the MTU announced by the RA's, if no MTU is announced then it uses a configured minimum MTU for that link and retransmits the query without any "MTU padding" options. This supports multiple MTU's on the same link. This consumes more bandwidth (the padding) during neighbour solicitation which is a "rare" event (only once per host pair, not per connection, or worse, per packet). Neighbour solicitation messages should go to multicast addresses that are likely to be used by at most only a few nodes, so the extra bandwidth used by the padding isn't excessive. This doesn't introduce more round trips however step down could be implemented with more round trips if desired. The test is "admin proof", admins shouldn't need to do any configuration for a host to start using large MTU's. If the network is poorly designed with an "invisible" low MTU link then the hosts will fall back correctly. This should recover from changes in MTU since new neighbour discoverys will discover the new link MTU. It's backwards compatible (nodes that don't understand this protocol MUST silently ignore the option according to RFC2461). The test should be reasonably robust, if a network cannot support[2] large mtus then the protocol will fall back to the minimum size. Problems with this protocol include that it can detect the existence of a "jumbogram path", and if it doesn't find it at the "preferred MTU" then it falls back to the lowest common denominator and doesn't detect intermediate sizes. It "wastes" bandwidth by padding neighbour solicitation/advertisement packets. This also assumes that MTU paths are symmetric. Options can only be 256 bytes long (there is an 8 byte length field for options), so a lot of options are required to pad a neighbour solicitation/advertisement to 9k. This could be resolved by changing the neighbour discovery protocol to use another (longer) length field if the length field is 0 (RFC 2461 explicitly says you must drop packets that have this set). This change would have much more impact however. If this sounds insane, in my defense it's 3am and sounded like a good idea at the time :) Perry ---- [1]: A host for instance may support receiving 9k MTU packets, but that doesn't mean that it doesn't prefer them to be under 4k, so a host can ask for it to be sent 4k MTU packets. [2]: Cannot support because of MTU issues, or due to high loss rates etc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jul 23 12:09:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwMYo-00040l-AZ; Sat, 23 Jul 2005 12:09:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwMYm-00040Z-B2 for ipv6@megatron.ietf.org; Sat, 23 Jul 2005 12:09:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05514 for ; Sat, 23 Jul 2005 12:09:05 -0400 (EDT) Received: from smta01.mail.ozemail.net ([203.103.165.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwN3E-0001iW-Ft for ipv6@ietf.org; Sat, 23 Jul 2005 12:40:38 -0400 Received: from ubu.nosense.org ([210.84.225.248]) by smta01.mail.ozemail.net with ESMTP id <20050723160856.ULZG6478.smta01.mail.ozemail.net@ubu.nosense.org>; Sat, 23 Jul 2005 16:08:56 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 52BAD62AAE; Sun, 24 Jul 2005 01:38:55 +0930 (CST) Date: Sun, 24 Jul 2005 01:38:55 +0930 From: Mark Smith To: Fred Baker Message-Id: <20050724013855.3f5839bd.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <96750F15-9FDA-4751-909E-66EB4BAEC002@cisco.com> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> <96750F15-9FDA-4751-909E-66EB4BAEC002@cisco.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; 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.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, iljitsch@muada.com, bob.hinden@nokia.com Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Fri, 22 Jul 2005 14:00:40 -0700 Fred Baker wrote: > In my personal view, networks like this are a fact of life. One > frequently is handed things by disparate people with disparate > budgets, responsibilities, and requirements. For example, perhaps IT > provides the switch, the router is what the managed-service ISP > installed several years ago and still works, and the servers are what > the department bought for this nifty-keeno application they're in the > process of installing. > I see above scenario possibly becoming quite common in the near future in a residential/SOHO scenario. GigE NICs and switches are dramatically coming down in price, and are commonly available in "commodity" type computer and office shops, where "joe six pack" also goes to buy his PC supplies. While the low end GigE switches don't seem to support jumbo frames yet, I doubt it will be long before they do. When jumbo frame capable commodity switches become available, their owners are unlikely to also be prepared to throw away their still quite capable ADSL/Cable router, yet will be disappointed when they aren't able to take advantage of the jumbo frame performance they've just spent money on between the nodes they've just installed GigE NICs in. 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 Jul 23 12:27:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwMq6-0002Lw-D8; Sat, 23 Jul 2005 12:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwMq4-0002Lq-Ms for ipv6@megatron.ietf.org; Sat, 23 Jul 2005 12:27:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06650 for ; Sat, 23 Jul 2005 12:26:57 -0400 (EDT) Received: from smta09.mail.ozemail.net ([203.103.165.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwNKX-0002DU-U0 for ipv6@ietf.org; Sat, 23 Jul 2005 12:58:30 -0400 Received: from ubu.nosense.org ([210.84.225.248]) by smta09.mail.ozemail.net with ESMTP id <20050723162656.KKNA1100.smta09.mail.ozemail.net@ubu.nosense.org>; Sat, 23 Jul 2005 16:26:56 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 5882D62AAE; Sun, 24 Jul 2005 01:56:54 +0930 (CST) Date: Sun, 24 Jul 2005 01:56:54 +0930 From: Mark Smith To: "Stephen Sprunk" Message-Id: <20050724015654.56d485c9.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <017901c58eec$cbf479b0$6701a8c0@dax> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; 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.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: iljitsch@muada.com, ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Stephen, On Fri, 22 Jul 2005 13:20:40 -0500 "Stephen Sprunk" wrote: > Thus spake "Mark Smith" > > Thinking about this a bit more, this could probably be fairly easy to > > achieve by creating a "onlink-MRU" or "interface-MRU" option for ND > > Neighbour Advertisements. There'd need to be some logic in how a > > sending node selects the size of the packets that it sends to a > > neighbour, based on comparing the values of its own local interface > > MTU, the link's MTU as announced in the RA(s) and the target > > neighbours announced onlink-MRU, if it announces one. > ... > > If there aren't any big holes in what I'm suggesting, I'm willing to > > spend some time co-authoring an Internet draft on this. > > The hole is that there may be an L2 device in the middle which has a lower > MTU than the end hosts. The neighbor MTU is an upper bound, but it's not > guaranteed to work -- you need to probe to see what really works. > I agree that probing would be nice to have, however I don't think not having it is a "black" hole. When a larger than standard MTU is used (e.g., 9K jumbos over GigE verses the 802.3 standard of 1500), the operator has made a conscious decision to increase the MTU, and therefore needs to take responsibility for ensuring that intermediary layer 2 devices support the increased MTU. People who want use jumbo frames on GigE interfaces know usually that they have to also have jumbo frame capable switches.. If we make the assumption that the intermediary link layer devices support the largest node MTU/MRU on the segment, I think the problem becomes a lot simpler, and then the issues to solve are : (a) how to ensure large MTU/MRU capable end nodes use them when communicating between each other. (b) how to ensure end-nodes with smaller MTU/MRUs are not sent too large frames by the large MTU/MRU capable end-nodes. I think either of these issues could be solved by using a ND NS/NA MRU type option, and, because RAs can carry a link-layer address, negating the need for a node to perform a ND NS/NA transaction with the router, at least initially, have an RA also possibly carry an MRU indication. For multicast, the link standard MTU or the link RA announced MTU would be used. For nodes that don't implement this "MRU" option, they'll use the link standard MTU to communicate with their neighbours and vice-versa, as per IPv6 operation today. I do agree this is in some respects a half-way step - it would be better if a method of probing could take place within the link to cope with a diversity of MTU/MRU capabilities and limitations, including those of intermediarly layer 2 devices. Still, I think if the above allows people to mix and match differing speed and MTU nodes on a layer 2 infrastructure that is known to support the largest-possible node MTU/MRU, it could be beneficial. 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 Jul 23 13:48:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwO6b-00027f-15; Sat, 23 Jul 2005 13:48:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwO6V-00024C-47 for ipv6@megatron.ietf.org; Sat, 23 Jul 2005 13:48:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10311 for ; Sat, 23 Jul 2005 13:48:01 -0400 (EDT) Received: from portier.titania.net ([66.134.191.110] helo=monet.titania.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwOax-0004JC-15 for ipv6@ietf.org; Sat, 23 Jul 2005 14:19:33 -0400 Received: from [192.133.102.8] (renoir.titania.net [192.133.102.8]) by monet.titania.net (8.13.3/8.13.3) with ESMTP id j6NHlksm029374 for ; Sat, 23 Jul 2005 17:47:47 GMT (envelope-from jtk@titania.net) Message-ID: <42E282BD.8020705@titania.net> Date: Sat, 23 Jul 2005 12:47:41 -0500 From: "Joseph T. Klein" User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <20050724015654.56d485c9.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050724015654.56d485c9.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (monet.titania.net [66.134.191.110]); Sat, 23 Jul 2005 17:47:47 +0000 (UTC) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Perhaps this wheel has been invented before? This sounds like MTU discovery. RFC 1063 ?? Mark Smith wrote: > Hi Stephen, > > On Fri, 22 Jul 2005 13:20:40 -0500 > "Stephen Sprunk" wrote: > > >>Thus spake "Mark Smith" >> >>>Thinking about this a bit more, this could probably be fairly easy to >>>achieve by creating a "onlink-MRU" or "interface-MRU" option for ND >>>Neighbour Advertisements. There'd need to be some logic in how a >>>sending node selects the size of the packets that it sends to a >>>neighbour, based on comparing the values of its own local interface >>>MTU, the link's MTU as announced in the RA(s) and the target >>>neighbours announced onlink-MRU, if it announces one. >> >>... >> >>>If there aren't any big holes in what I'm suggesting, I'm willing to >>>spend some time co-authoring an Internet draft on this. >> >>The hole is that there may be an L2 device in the middle which has a lower >>MTU than the end hosts. The neighbor MTU is an upper bound, but it's not >>guaranteed to work -- you need to probe to see what really works. >> > > > I agree that probing would be nice to have, however I don't think not > having it is a "black" hole. > > When a larger than standard MTU is used (e.g., 9K jumbos over GigE > verses the 802.3 standard of 1500), the operator has made a conscious > decision to increase the MTU, and therefore needs to take responsibility > for ensuring that intermediary layer 2 devices support the increased > MTU. People who want use jumbo frames on GigE interfaces know usually > that they have to also have jumbo frame capable switches.. > > If we make the assumption that the intermediary link layer devices support the > largest node MTU/MRU on the segment, I think the problem becomes a lot > simpler, and then the issues to solve are : > > (a) how to ensure large MTU/MRU capable end nodes use them when > communicating between each other. > > (b) how to ensure end-nodes with smaller MTU/MRUs are not sent too large > frames by the large MTU/MRU capable end-nodes. > > I think either of these issues could be solved by using a ND NS/NA MRU > type option, and, because RAs can carry a link-layer address, negating > the need for a node to perform a ND NS/NA transaction with the router, > at least initially, have an RA also possibly carry an MRU indication. > > For multicast, the link standard MTU or the link RA announced MTU would > be used. > > For nodes that don't implement this "MRU" option, they'll use the link > standard MTU to communicate with their neighbours and vice-versa, as per > IPv6 operation today. > > I do agree this is in some respects a half-way step - it would be better > if a method of probing could take place within the link to cope with a > diversity of MTU/MRU capabilities and limitations, including those of > intermediarly layer 2 devices. Still, I think if the above allows people > to mix and match differing speed and MTU nodes on a layer 2 > infrastructure that is known to support the largest-possible node > MTU/MRU, it could be beneficial. > > 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 Sat Jul 23 15:49:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwPze-0004Uy-Tl; Sat, 23 Jul 2005 15:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwPzc-0004UN-WF for ipv6@megatron.ietf.org; Sat, 23 Jul 2005 15:49:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17402 for ; Sat, 23 Jul 2005 15:49:02 -0400 (EDT) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwQU8-0007Ot-4O for ipv6@ietf.org; Sat, 23 Jul 2005 16:20:36 -0400 Received: from dax (ip178.post-vineyard.dfw.ygnition.net [66.135.181.178]) by ns2.sea (8.13.4/8.12.5) with SMTP id j6NJmYEK011067; Sat, 23 Jul 2005 12:48:40 -0700 Message-ID: <022401c58fbf$86727260$6701a8c0@dax> From: "Stephen Sprunk" To: "Iljitsch van Beijnum" References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> Date: Sat, 23 Jul 2005 14:45:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns2.sea id j6NJmYEK011067 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thus spake "Iljitsch van Beijnum" > On 22-jul-2005, at 20:20, Stephen Sprunk wrote: >>> Thinking about this a bit more, this could probably be fairly easy to >>> achieve by creating a "onlink-MRU" or "interface-MRU" option for ND >>> Neighbour Advertisements. > >>> If there aren't any big holes in what I'm suggesting, I'm willing to >>> spend some time co-authoring an Internet draft on this. > > I'm sure we can find a nice restaurant or caf=E9 in Paris to discuss t= he=20 > matter further. :-) I'm not able to attend, so I'd appreciate it if someone would give my=20 comments a bit of airtime even if none of the attendees agree with me. >> The hole is that there may be an L2 device in the middle which has a=20 >> lower MTU than the end hosts. The neighbor MTU is an upper bound, bu= t=20 >> it's not guaranteed to work -- you need to probe to see what really=20 >> works. > > (Layer 1 devices can also impose MTU limits.) True; read the above L2 as L1/L2. > It's important to keep this simple, unless the IEEE guys also want > to play and add mechanisms to exchange MTU information between > switches. Given their past stance on jumbos, I don't see that happening. >> Just like PMTUD, you need to periodically probe and adjust to changin= g=20 >> network conditions, including detecting "black holes". Fred Baker=20 >> suggested the host send both minimum MTU (576 for >> v4 and 1280 for v6) and maximum MTU frames in a given burst >> and track what gets through. > > I'm not really comfortable with this... It makes more sense to me to h= ave=20 > a router or two, or maybe one or two non-router hosts, send out "MTU=20 > announcements", and other hosts only announce the non- > standard MTU in neighbor advertisements when they recently heard > one of those announcements. When the MTU suddenly decreasees, > the announcements are no longer heard, hosts put 1500 in their > neighbor advertisements and neighbor unreachability detection does > the rest. I'm okay with hosts dropping to 1500 (assuming Ethernet) for neighbors th= at=20 can't receive jumbos. It'd be desirable for them to find a higher value=20 that works but which is still less than both hosts' MTUs. Trying to ratc= het=20 the MTU back up after it's been lowered is probably more trouble than it'= s=20 worth. > The fact that ethernet is supposed to have a tree topology makes > things slightly simpler. Some 802 networks are not trees, and there are non-802 networks out there= .=20 I'd like to have a single jumbo spec for all L1/L2 types; it doesn't seem= to=20 require much tap-dancing around the specific numbers to generalize it to = all=20 media types, though obviously Ethernet is the most common and most in nee= d=20 of help. >> The most perverse scenario I can envision is a network where one host= =20 >> has an MTU of 9k, another has 8k, one network path has 10k, another p= ath=20 >> has 3k, and the path varies every few minutes (and isn't necessarily=20 >> symmetric). > > Real-life ethernet isn't supposed to be like that... I've been traumatized by some of the networks I've seen in the wild. The= =20 scenario I gave was deliberately perverse, but it's not very far from the= =20 worst I've encountered -- and I guarantee such things will occur if we=20 standardize jumbos. I'm betting that's why the IEEE refused to tackle it. > For those who think there isn't a real problem here: it takes a little > over 800 packets per second to saturate a 10 Mbps ethernet link. > At GE speeds that's 80000 packets per second. It is very hard to > achieve decent performance when you have to stop what you're doing 800= 00=20 > times per second... Modern hosts can do it, but it'd be nice to reduce the CPU load due to NI= C=20 interrupts if possible. > There is also the environment to consider because the amount of > power switches use is strongly related to the number of packets that > flow through the switch. So increasing the MTU from (for instance) > 1500 to 9000 bytes means it only takes 3 packets to transfer 18000 > bytes (2 data, 1 ack), while it takes (best case) 13 packets at 1500 > bytes (12 data, 1 ack) but usually 18 (6 acks). That saves a LOT > of power. The power consideration didn't even occur to me; I was thinking of CPU lo= ad=20 on end hosts, per-packet overhead on the wire, and pps limits on network=20 gear. 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=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 Jul 23 15:49:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwPzf-0004VQ-P3; Sat, 23 Jul 2005 15:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwPzc-0004UK-WF for ipv6@megatron.ietf.org; Sat, 23 Jul 2005 15:49:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17401 for ; Sat, 23 Jul 2005 15:49:02 -0400 (EDT) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwQU8-0007Ox-4S for ipv6@ietf.org; Sat, 23 Jul 2005 16:20:36 -0400 Received: from dax (ip178.post-vineyard.dfw.ygnition.net [66.135.181.178]) by ns2.sea (8.13.4/8.12.5) with SMTP id j6NJmYEI011067; Sat, 23 Jul 2005 12:48:34 -0700 Message-ID: <022301c58fbf$8623b620$6701a8c0@dax> From: "Stephen Sprunk" To: "Mark Smith" References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org><20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org><017901c58eec$cbf479b0$6701a8c0@dax> <20050724015654.56d485c9.ipng@69706e6720323030352d30312d31340a.nosense.org> Date: Sat, 23 Jul 2005 14:16:46 -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.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: iljitsch@muada.com, ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thus spake "Mark Smith" > On Fri, 22 Jul 2005 13:20:40 -0500 > "Stephen Sprunk" wrote: >> The hole is that there may be an L2 device in the middle which has >> a lower MTU than the end hosts. The neighbor MTU is an upper >> bound, but it's not guaranteed to work -- you need to probe to see >> what really works. > > I agree that probing would be nice to have, however I don't think not > having it is a "black" hole. > > When a larger than standard MTU is used (e.g., 9K jumbos over > GigE verses the 802.3 standard of 1500), the operator has made a > conscious decision to increase the MTU, and therefore needs to > take responsibility for ensuring that intermediary layer 2 devices > support the increased MTU. People who want use jumbo frames > on GigE interfaces know usually that they have to also have > jumbo frame capable switches.. Except we nearly have this situation today -- jumbos only work if the admin goes through a lot of painstaking effort to make sure they do. You're proposing we eliminate the per-host effort but not the network-side effort; to me that's a half-solution (as you granted in a section I snipped). I want jumbos to work out of the box without the admin (which might be my grandmother at home) even knowing what jumbos are. > If we make the assumption that the intermediary link layer devices > support the largest node MTU/MRU on the segment, I think the > problem becomes a lot simpler, and then the issues to solve are : > > (a) how to ensure large MTU/MRU capable end nodes use them > when communicating between each other. > > (b) how to ensure end-nodes with smaller MTU/MRUs are not sent > too large frames by the large MTU/MRU capable end-nodes. > > I think either of these issues could be solved by using a ND NS/NA > MRU type option, and, because RAs can carry a link-layer address, > negating the need for a node to perform a ND NS/NA transaction > with the router, at least initially, have an RA also possibly carry > an MRU indication. The RA's MRU would make a good upper bound, but you still need to probe to make sure a host you're talking to isn't sitting behind some $30 hub that silently drops jumbos (er, giants). And you have to keep probing in case the host moves or the L1/L2 path changes, unless you've recently received from that host a jumbo or ACK for your own jumbo. The reason I think this is necessary is that it allows hosts supporting jumbos to have them on by default and gracefully fall back to non-jumbo sizes in the presence of non-jumbo-aware hosts or network devices. You can only have them on by default if you're sure you can handle the most perverse case (which I think I presented). > For multicast, the link standard MTU or the link RA announced MTU > would be used. I'm not sure using an MTU above 1500 for multicast should be legal; there may be hosts on the subnet which we don't know are neighbors and thus we don't know the lowest MRU out there. Also, aren't there cases where we'll know of a neighbor but wouldn't have had to do ND and thus wouldn't have learned their MRU? > For nodes that don't implement this "MRU" option, they'll use the link > standard MTU to communicate with their neighbours and vice-versa, > as per IPv6 operation today. Of course. And, since I know this is the IPv6 WG list, which WG would be appropriate to discuss back-porting this feature into IPv4 after we solve it for IPv6? 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 Sat Jul 23 22:51:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwWac-0004Sd-Fk; Sat, 23 Jul 2005 22:51:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwWaa-0004Rn-Mq for ipv6@megatron.ietf.org; Sat, 23 Jul 2005 22:51:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05803 for ; Sat, 23 Jul 2005 22:51:37 -0400 (EDT) Received: from smta07.mail.ozemail.net ([203.103.165.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwX59-0008H5-82 for ipv6@ietf.org; Sat, 23 Jul 2005 23:23:16 -0400 Received: from ubu.nosense.org ([210.84.225.248]) by smta07.mail.ozemail.net with ESMTP id <20050724025130.QNKB20373.smta07.mail.ozemail.net@ubu.nosense.org>; Sun, 24 Jul 2005 02:51:30 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 6878662AAE; Sun, 24 Jul 2005 12:21:28 +0930 (CST) Date: Sun, 24 Jul 2005 12:21:28 +0930 From: Mark Smith To: "Stephen Sprunk" Message-Id: <20050724122128.1940b64c.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <022301c58fbf$8623b620$6701a8c0@dax> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <20050724015654.56d485c9.ipng@69706e6720323030352d30312d31340a.nosense.org> <022301c58fbf$8623b620$6701a8c0@dax> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; 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.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Cc: iljitsch@muada.com, ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Sat, 23 Jul 2005 14:16:46 -0500 "Stephen Sprunk" wrote: > Thus spake "Mark Smith" > > On Fri, 22 Jul 2005 13:20:40 -0500 > > "Stephen Sprunk" wrote: > >> The hole is that there may be an L2 device in the middle which has > >> a lower MTU than the end hosts. The neighbor MTU is an upper > >> bound, but it's not guaranteed to work -- you need to probe to see > >> what really works. > > > > I agree that probing would be nice to have, however I don't think not > > having it is a "black" hole. > > > > When a larger than standard MTU is used (e.g., 9K jumbos over > > GigE verses the 802.3 standard of 1500), the operator has made a > > conscious decision to increase the MTU, and therefore needs to > > take responsibility for ensuring that intermediary layer 2 devices > > support the increased MTU. People who want use jumbo frames > > on GigE interfaces know usually that they have to also have > > jumbo frame capable switches.. > > Except we nearly have this situation today -- jumbos only work if the admin > goes through a lot of painstaking effort to make sure they do. You're > proposing we eliminate the per-host effort but not the network-side effort; > to me that's a half-solution (as you granted in a section I snipped). I > want jumbos to work out of the box without the admin (which might be my > grandmother at home) even knowing what jumbos are. > Remember that the per-host effort is where a lot of the effort is - there are just so many more of them than there are layer 2 infrastructure devices. I'd like "ultimate plug-and-play" for this scenario, however, for quite valid reasons, that problem is either quite hard or even impossible to solve. The fundamentaly issue I think I'm really addressing is that even if the administrator goes to the effort of ensuring that the layer 2 intermediary devices support jumbo frames, IPv6 currently prevents you taking advantage of it for the hosts that support it, the moment you plug in one legacy device that doesn't. For example, you may have a few hundred hosts that support jumbo frames, and layer 2 switching infrastructure that also supports jumbo frames. You then want to plug in an older 10 or 100Mbps network attach printer (that has been software upgraded to support IPv6) that doesn't. That printer hobles all the hosts to using 1500 byte frames for IPv6. Sure, you can fix that by buying or building a 2 interface router that supports jumbo ethernet frames on at least one interface, and then plugging the printer into the other interface, creating a different MTU'd segment. Thats a fairly $$$$ or time intensive solution. I'd think modifying IPv6 to support this scenario (again, assuming layer 2 infrastructure supports the largest MTU/MRU) would be very much appreciated by people who design a network like this and are then faced with the idea of having to buy/build a router just to support an existing, legacy printer. "Legacy" printers could with any other "legacy hardware" device that has been software upgraded to support IPv6, e.g. router, host, scientific equipment etc. > > If we make the assumption that the intermediary link layer devices > > support the largest node MTU/MRU on the segment, I think the > > problem becomes a lot simpler, and then the issues to solve are : > > > > (a) how to ensure large MTU/MRU capable end nodes use them > > when communicating between each other. > > > > (b) how to ensure end-nodes with smaller MTU/MRUs are not sent > > too large frames by the large MTU/MRU capable end-nodes. > > > > I think either of these issues could be solved by using a ND NS/NA > > MRU type option, and, because RAs can carry a link-layer address, > > negating the need for a node to perform a ND NS/NA transaction > > with the router, at least initially, have an RA also possibly carry > > an MRU indication. > > The RA's MRU would make a good upper bound, but you still need to probe to > make sure a host you're talking to isn't sitting behind some $30 hub that > silently drops jumbos (er, giants). And you have to keep probing in case > the host moves or the L1/L2 path changes, unless you've recently received > from that host a jumbo or ACK for your own jumbo. > If you've gone to the effort of consciously building a jumbo capable infrastructure, and then chosen to use it, and then somebody else ('cause it won't be you) plugs in a $30 hub, then (a) you can repremand them (b) be sure that the problem will be localised to the devices on the other side of the hub, if they try to plug jumbo capable devices in behind it, and attempt to use jumbo frames. The existing, properly supported jumbo capable devices plugged into the proper jumbo capable layer 2 infrastructure would continue to work properly. If they plug in jumbo frame capable devices behind the hub (forgetting for the moment that hubs don't come in GigE flavour), but don't enable jumbo frames on the end-nodes, things will work as normal. Again, remember that my suggestion solution is _constrained_ to scenarios where the layer 2 infrastructure has been specifically designed to support jumbo frames, and a conscious effort has been made to enable them. My solution has the fundamental goal of allowing small-MTU, "legacy" end-nodes (e.g., printers, routers, etc.) to be plugged into the same layer 2 infrastructure without those legacy devices hobbling the MTU/MRUs the jumbo capable devices support. I think this scenario is or will be quite common in the future. I'd suggest that buying GigE layer 2 switching without looking at its features, capabilities and specifications, is only limited to the residential, SOHO and maybe small business market. IOW, any scenario where the network is actually designed may benefit from this MTU/MRU discovery solution for unicast traffic. Those networks are present in medium to large businesses, and service providers, and I think there will be lots of "_designed_ to support jumbo" frame networks in the future. > The reason I think this is necessary is that it allows hosts supporting > jumbos to have them on by default and gracefully fall back to non-jumbo > sizes in the presence of non-jumbo-aware hosts or network devices. You can > only have them on by default if you're sure you can handle the most perverse > case (which I think I presented). > > > For multicast, the link standard MTU or the link RA announced MTU > > would be used. > > I'm not sure using an MTU above 1500 for multicast should be legal; there > may be hosts on the subnet which we don't know are neighbors and thus we > don't know the lowest MRU out there. Also, aren't there cases where we'll > know of a neighbor but wouldn't have had to do ND and thus wouldn't have > learned their MRU? > They wouldn't be legal, as the multicast scenario is exactly why RFC2461 says the MTU has to be of a fixed size for the segment. However, once we apply this constraint only to multicast traffic, we then may be able to allowing differing MTU/MRUs for unicast traffic between hosts on the same link (of course, again, assuming that the layer 2 infrastructure supports the largest MTU/MRU). > > For nodes that don't implement this "MRU" option, they'll use the link > > standard MTU to communicate with their neighbours and vice-versa, > > as per IPv6 operation today. > > Of course. > > And, since I know this is the IPv6 WG list, which WG would be appropriate to > discuss back-porting this feature into IPv4 after we solve it for IPv6? > We choose not to back-port (it may not be possible anyway as I don't think ARP is extensible like IPv6 ND is), and that will then provide another reason to migrate to IPv6 ... :-) Back-porting nice features from IPv6 to IPv4 is possibly false economy. It takes extra effort (even though it may be a small amount), which instead could be used to further improve IPv6, and also provides additional disincentives to adopt IPv6. In some ways it reminds me of the effort that is spent overcoming NAT limitations, rather than more usefully either improving the application by adding features, or porting the application to IPv6 and avoiding then avoiding NAT issues completely. 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 Jul 24 00:00:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwXfM-0002Ze-Mg; Sun, 24 Jul 2005 00:00:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwXfK-0002XP-1a for ipv6@megatron.ietf.org; Sun, 24 Jul 2005 00:00:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09003 for ; Sun, 24 Jul 2005 00:00:34 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwY9r-0001aE-FK for ipv6@ietf.org; Sun, 24 Jul 2005 00:32:13 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id E044161A for ; Sun, 24 Jul 2005 00:00:17 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 24 Jul 2005 00:00:17 -0400 Message-Id: <20050724040017.E044161A@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 10.13% | 8 | 10.31% | 54655 | elwynd@dial.pipex.com 7.59% | 6 | 8.58% | 45463 | ipng@69706e6720323030352d30312d31340a.nosense.org 5.06% | 4 | 8.18% | 43354 | ronald.pashby.ctr@navy.mil 3.80% | 3 | 7.46% | 39519 | marcelo@it.uc3m.es 6.33% | 5 | 4.61% | 24439 | samita.chakrabarti@eng.sun.com 5.06% | 4 | 3.52% | 18629 | jinmei@isl.rdc.toshiba.co.jp 5.06% | 4 | 3.46% | 18354 | hirose@comm.yamaha.co.jp 2.53% | 2 | 5.56% | 29441 | kosuke@bugest.net 2.53% | 2 | 5.48% | 29055 | alh-ietf@tndh.net 5.06% | 4 | 2.91% | 15437 | bob.hinden@nokia.com 3.80% | 3 | 3.79% | 20095 | stephen@sprunk.org 3.80% | 3 | 2.89% | 15290 | iljitsch@muada.com 2.53% | 2 | 3.82% | 20259 | jordi.palet@consulintel.es 2.53% | 2 | 3.54% | 18783 | brian.haley@hp.com 2.53% | 2 | 2.38% | 12610 | internet-drafts@ietf.org 2.53% | 2 | 2.14% | 11315 | fred@cisco.com 2.53% | 2 | 2.10% | 11119 | brc@zurich.ibm.com 2.53% | 2 | 1.98% | 10487 | albert.e.manfredi@boeing.com 2.53% | 2 | 1.65% | 8722 | hugh.lamaster@nasa.gov 2.53% | 2 | 1.54% | 8168 | fujisaki@syce.net 1.27% | 1 | 2.49% | 13186 | timbeck04@verizon.net 1.27% | 1 | 1.33% | 7057 | perry@coders.net 1.27% | 1 | 1.28% | 6798 | jtk@titania.net 1.27% | 1 | 0.87% | 4628 | gert@space.net 1.27% | 1 | 0.87% | 4595 | raul@lacnic.net 1.27% | 1 | 0.86% | 4535 | jeroen@unfix.org 1.27% | 1 | 0.83% | 4393 | sra+ipng@hactrn.net 1.27% | 1 | 0.80% | 4215 | john.loughney@nokia.com 1.27% | 1 | 0.75% | 3999 | vladislav.yasevich@hp.com 1.27% | 1 | 0.75% | 3998 | randy@psg.com 1.27% | 1 | 0.73% | 3890 | stig.venaas@uninett.no 1.27% | 1 | 0.68% | 3612 | support@paypal.com 1.27% | 1 | 0.65% | 3431 | keiichi@iijlab.net 1.27% | 1 | 0.61% | 3220 | scipolli@radvision.com 1.27% | 1 | 0.60% | 3169 | iesg-secretary@ietf.org --------+------+--------+----------+------------------------ 100.00% | 79 |100.00% | 529920 | 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 ipv6-bounces@ietf.org Sun Jul 24 07:41:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwerQ-0004UI-7p; Sun, 24 Jul 2005 07:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwerN-0004UD-SU for ipv6@megatron.ietf.org; Sun, 24 Jul 2005 07:41:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21738 for ; Sun, 24 Jul 2005 07:41:32 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwfM1-0008HM-Ec for ipv6@ietf.org; Sun, 24 Jul 2005 08:13:14 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6OBfck0060607 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 24 Jul 2005 13:41:39 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <42E25E62.2010805@coders.net> References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> <42E25E62.2010805@coders.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17E800F8-AAFF-4B67-8CF9-42CB69038694@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Sun, 24 Jul 2005 13:40:53 +0200 To: Perry Lorier X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 23-jul-2005, at 17:12, Perry Lorier wrote: > Before two hosts can transmit packets on Ethernet they have to undergo > neighbour solicitation to find the remote ends hardware address > anyway. Right. > When you send the neighbour solicitation you could pad the packet out > with multiple "MTU padding" options to make the packet the size of the > MTU you want to use. I don't think we want to do this in the neighbor _solicitation_ because there is a good chance that the neighbor doesn't support the larger MTU so the packet is lost. > If the original host does not receive a reply, it updates it's > neighbour > cache to say that the MTU supported is the MTU announced by the > RA's, if > no MTU is announced then it uses a configured minimum MTU for that > link > and retransmits the query without any "MTU padding" options. This is problematic for two reasons: when the packet gets lost because either the receiver or the layer 2 network don't support a sufficiently large MTU/MRU, there is a timeout, which wastes time, and if the receiver does in fact support jumboframes but of a smaller size than the sender supports, this isn't detected. > If this sounds insane, in my defense it's 3am and sounded like a good > idea at the time :) :-) I think our requirements are: 1. do not impede 1500-byte operation 2. discover and utilize jumboframe capability where possible 3. discover and utilize (close to) the maximum MTU 4. recover from sudden MTU reductions fast enough for TCP and similar to survive First of all, we need for hosts to find out that their correspondents support a larger MTU/MRU. This can easily be done in an ND option. Since we're not going to get cooperation from switches, let alone hubs, it's important that we send test packets to see whether the jumboframes actually make it to the other side. I think using ND for this isn't a good idea: in its current form, it doesn't support the required packet size, and when the padded packet doesn't make it, there recovery complexities and delays. So it makes sense to come up with a new protocol for this. An interesting notion here is that this protocol doesn't have to be IPv6- specific. However, in IPv6 we have neighbor unreachability detection which we can use to find MTU reductions fast enough to fall back to 1500 bytes before bad things happen. In IPv4 or pure ethernet, we don't have that, and we also don't have neighbor discovery to exchange per-host MRU/MTU information. If we use IPv6 for this, I think a new ICMP type makes sense. Whenever two systems (hosts or routers) on a link perform neighbor discovery, they can trigger the MTU verficiation immediately afterward, and if jumboframe support is confirmed by receiving the larger packets, the MTU for the the neighbor can be updated. If the larger packets don't make it to the neighbor there is no complexity and no delay: communication was already underway at 1500 bytes and continues without the need for further action. However, this doesn't accommodate finding out jumboframe support at reduced sizes very well. For this, I think we should use an additional exchange, but this one should probably happen over multicast. Hosts/routers could take turns in a distributed search for the largest supported framesize. I think it's important that all jumbo-capable systems take part in this in order to deal with unusual topologies. For instance, consider a network with three switches: one support 9000, another 8000 and the two are connected through a third switch that only supports 3000 bytes: A C | | +-+--+ +----+ +--+-+ |9000+--+3000+--+8000| +-+--+ +----+ +--+-+ | | B D Suppose all hosts support 9216 byte jumboframes. I think the most efficient way to handle this is to do two concurrent searches: one for the maximum packet size that can be used to at least one correspondent, and one for the minimum jumboframe size that is supported by all jumboframe supporting systems. So first A sends out an announcement that it's going to send a 9216 byte and a 5596 (1500 + 4096) byte packet, and then sends the packets. Nobody receives the first packet, but everyone knows A sent it because of the preceding announcement, and B receives the second packet. Then B would (for instance) send out its 9216 byte packet along with a 1500 + 2048 = 3548 byte packet, and also indicates the largest size that worked (5596) and the smallest size that didn't work (9126). A receives the 3548 byte packet but not the 9216 byte one. C is next and sends out 9216 and (1500 + 1024 = ) 2524 byte packets, along with the information that no jumboframe size has worked so far. A, B and D all receive the 2524 byte packet. D then sends out 9216 and (1500 + 1536 = ) 3036 byte packets with information that it received 2524 but not 3548. C receives the 3036 byte packet. It's now A's turn again. A knows that the size that everyone can receive is betweeen 2524 and 3036 and the size that at least one correspondent can receive is between 5596 and 9216. So it sends out 2780 and 7406 byte packets. And so on. After a few round like this, each system knows the maximum jumboframe size it can send/receive (so it can adjust its announcements in the ND option), and the minimum jumboframe size that everyone supports. It's probably doable to generalize this into any given number of levels, but I doubt that more than 3 is worth the trouble, and maybe having two levels even isn't. On the other hand, if some hosts support 9000 but the majority support 8192 it may be a good idea to forget 9000 and just do 8192. This may sound horribly complex, but it really isn't. :-) The biggest challenge is probably making the different systems talk in turn, but that can probably be done by having a timer that depends on the difference in MAC address between the last system to transmit and prospective next one. Extra credit: monitor spanning tree events for quick adaption to changing layer 2 topologies. Alternatively, we could add an RA option that administrators can use to tell hosts the jumboframe size the layer 2 network supports. (The RA option doesn't say anything about the capabilities of the _router_.) Then the whole multicast taking turns discovery isn't necessary, and we can suffice with a quick one-to-one verification before jumboframes are used. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jul 24 09:16:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwgLg-0001z5-8X; Sun, 24 Jul 2005 09:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwgLe-0001yx-7o for ipv6@megatron.ietf.org; Sun, 24 Jul 2005 09:16:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26468 for ; Sun, 24 Jul 2005 09:16:52 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx3.orcon.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwgqI-0002I2-5C for ipv6@ietf.org; Sun, 24 Jul 2005 09:48:35 -0400 Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx3.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j6ODIi42011757; Mon, 25 Jul 2005 01:18:45 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1DwgLL-0006fM-00; Mon, 25 Jul 2005 01:16:35 +1200 Message-ID: <42E394B2.5020409@coders.net> Date: Mon, 25 Jul 2005 01:16:34 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050724 X-Accept-Language: en-nz, en MIME-Version: 1.0 To: Iljitsch van Beijnum References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> <42E25E62.2010805@coders.net> <17E800F8-AAFF-4B67-8CF9-42CB69038694@muada.com> In-Reply-To: <17E800F8-AAFF-4B67-8CF9-42CB69038694@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/989/Sat Jul 23 09:27:30 2005 on dbmail-mx3.orcon.net.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > I think our requirements are: > > 1. do not impede 1500-byte operation > 2. discover and utilize jumboframe capability where possible > 3. discover and utilize (close to) the maximum MTU > 4. recover from sudden MTU reductions fast enough for TCP and similar > to survive I'd add to this list: 5. Must be fully automatic and not require any admin intervention to do the "right" thing. 6. Minimise the resources used. > So it makes sense to come up with a new protocol for this. An > interesting notion here is that this protocol doesn't have to be IPv6- > specific. However, in IPv6 we have neighbor unreachability detection > which we can use to find MTU reductions fast enough to fall back to > 1500 bytes before bad things happen. In IPv4 or pure ethernet, we don't > have that, and we also don't have neighbor discovery to exchange > per-host MRU/MTU information. > > If we use IPv6 for this, I think a new ICMP type makes sense. Yep, makes sense to me. :) > Whenever two systems (hosts or routers) on a link perform neighbor > discovery, they can trigger the MTU verficiation immediately > afterward, and if jumboframe support is confirmed by receiving the > larger packets, the MTU for the the neighbor can be updated. If the > larger packets don't make it to the neighbor there is no complexity > and no delay: communication was already underway at 1500 bytes and > continues without the need for further action. Yep! I'd considered this, but at 3am didn't want to confuse the issue by introducing too many differing ideas at the same time. (Also, I wanted to go to sleep :) You've seemed to have thought through some of the issues a bit better than I had too :) > However, this doesn't accommodate finding out jumboframe support at > reduced sizes very well. For this, I think we should use an additional > exchange, but this one should probably happen over multicast. I disagree. There is no need to for every host to have a full understanding of the layer 2 topology of the network it is on. We're starting to see some very large L2 networks as MAN's (eg NLR[1]) and IPv6's /64 per subnet puts no real practical limit on how large a single L2 segment can be. The storage requirements for all of this information alone is either going to be very large (remembering MTU's for every neighbour on the link?!) and/or it's going to have be repeated almost constantly as hosts want to discover MTU's to specific neighbours. Nodes that are reasonably "idle" on the link are going to have to participate in this and therefore avoid entering low power modes. Multicasting out "jumbo" packets is going to tax switch queue sizes to the extreme. A 48 port switch, receiving a single multicast 9k packet (that it can forward) may end up with 48*9k=430,000 bytes (or nearly 1/2 a megabyte) of buffer space used with a single packet arriving. What happens on l2's where not every node can see every other node? Some L2's only allow end hosts to talk to a master host. What about a network with vlans where some hosts are on differing sets of vlans? > Hosts/routers could take turns in a distributed search for the largest > supported framesize. I think it's important that all jumbo-capable > systems take part in this in order to deal with unusual topologies. For > instance, consider a network with three switches: one support 9000, > another 8000 and the two are connected through a third switch that only > supports 3000 bytes: > > > A C > | | > +-+--+ +----+ +--+-+ > |9000+--+3000+--+8000| > +-+--+ +----+ +--+-+ > | | > B D > > Suppose all hosts support 9216 byte jumboframes. If A and B are talking to each other and C and D are talking to each other, why do (A and B) need to talk to C and D? > I think the most efficient way to handle this is to do two concurrent > searches: one for the maximum packet size that can be used to at least > one correspondent, and one for the minimum jumboframe size that is > supported by all jumboframe supporting systems. Why not a simpler protocol? Host A sends a ND to Host B with Host A's MRU. Host B replies with a NS to Host A with Host B's MRU. Host A can now start transmitting the data it wants to send. Host A now sends Host B a ICMP MTU Probe, at some size less than or equal to Host B's MRU If Host B receives the packet, it replies with an ICMP MTU Probe reply saying what it received. By working "up" known sizes instead of doing a binary search (or working down), Host A can quickly ratchet up sizes without waiting for a timeout gaining immediate benefits from larger MTUs as they are discovered. Which sizes should it use? Well, there probably should be a hard coded list of "well known MTU sizes" which could perhaps be expanded at runtime (if you find an host with MTU that's not in that list, then add the MTU to it so you can more quickly find that MTU in future). > So first A sends out an announcement that it's going to send a 9216 > byte and a 5596 (1500 + 4096) byte packet, and then sends the packets. > Nobody receives the first packet, but everyone knows A sent it because > of the preceding announcement, and B receives the second packet. If you persist with this idea, switch the order of the packets sent. Send the packet first, then send the announcement that it was sent. Assuming no reordering you then don't have to wait for a timeout. If reordering does occur you then send a "Whoops! reordering! didn't expect that on the same L2!" and then everyone flags that interface as "possible reordering" and then always waits for a timeout. In the common case of no reordering this will be much faster due to not waiting for timeouts. > Then B would (for instance) send out its 9216 byte packet along with a > 1500 + 2048 = 3548 byte packet, and also indicates the largest size > that worked (5596) and the smallest size that didn't work (9126). A > receives the 3548 byte packet but not the 9216 byte one. > > C is next and sends out 9216 and (1500 + 1024 = ) 2524 byte packets, > along with the information that no jumboframe size has worked so far. > A, B and D all receive the 2524 byte packet. > > D then sends out 9216 and (1500 + 1536 = ) 3036 byte packets with > information that it received 2524 but not 3548. C receives the 3036 > byte packet. > > It's now A's turn again. A knows that the size that everyone can > receive is betweeen 2524 and 3036 and the size that at least one > correspondent can receive is between 5596 and 9216. So it sends out > 2780 and 7406 byte packets. > > And so on. > > After a few round like this, each system knows the maximum jumboframe > size it can send/receive (so it can adjust its announcements in the ND > option), and the minimum jumboframe size that everyone supports. It's > probably doable to generalize this into any given number of levels, but > I doubt that more than 3 is worth the trouble, and maybe having two > levels even isn't. On the other hand, if some hosts support 9000 but > the majority support 8192 it may be a good idea to forget 9000 and just > do 8192. > > This may sound horribly complex, but it really isn't. :-) > > The biggest challenge is probably making the different systems talk in > turn, but that can probably be done by having a timer that depends on > the difference in MAC address between the last system to transmit and > prospective next one. Not everything has a MAC address. Difference in link local addresses? This sounds very much like turning Ethernet into token ring . > Extra credit: monitor spanning tree events for quick adaption to > changing layer 2 topologies. Ooh, very good call. I'd not considered this! > Alternatively, we could add an RA option that administrators can use to > tell hosts the jumboframe size the layer 2 network supports. (The RA > option doesn't say anything about the capabilities of the _router_.) > Then the whole multicast taking turns discovery isn't necessary, and we > can suffice with a quick one-to-one verification before jumboframes are > used. This still seems to fall foul of either requiring the administrator to configure the router or degrading the entire network to the level of the router. Since routers are often the bottleneck (eg DSL in NZ is currently <=~2mbit, so why have a DSL router thats faster than 10mbit? 10mbit still has a low MTU, but hosts within the site should still try and use jumbograms) ---- [1]: National Lambda Rail claim to be the first national switched Ethernet (http://www.nlr.net/architecture.html) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jul 24 14:06:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwksF-0004cq-E4; Sun, 24 Jul 2005 14:06:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwksE-0004cl-1f for ipv6@megatron.ietf.org; Sun, 24 Jul 2005 14:06:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11957 for ; Sun, 24 Jul 2005 14:06:48 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwlMu-00016n-R2 for ipv6@ietf.org; Sun, 24 Jul 2005 14:38:33 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6OI74k0065298 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 24 Jul 2005 20:07:05 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <42E394B2.5020409@coders.net> References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> <42E25E62.2010805@coders.net> <17E800F8-AAFF-4B67-8CF9-42CB69038694@muada.com> <42E394B2.5020409@coders.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Iljitsch van Beijnum Date: Sun, 24 Jul 2005 20:06:22 +0200 To: Perry Lorier X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-4.4 required=5.0 tests=BAYES_00,LINES_OF_YELLING autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 24-jul-2005, at 15:16, Perry Lorier wrote: >> I think our requirements are: >> 1. do not impede 1500-byte operation >> 2. discover and utilize jumboframe capability where possible >> 3. discover and utilize (close to) the maximum MTU >> 4. recover from sudden MTU reductions fast enough for TCP and similar >> to survive > I'd add to this list: > 5. Must be fully automatic and not require any admin intervention =20 > to do > the "right" thing. > 6. Minimise the resources used. Agree, except that packets are cheap on a 1000 Mbps LAN, so those =20 don't count much towards 6. >> Whenever two systems (hosts or routers) on a link perform neighbor >> discovery, they can trigger the MTU verficiation immediately >> afterward, and if jumboframe support is confirmed by receiving the >> larger packets, the MTU for the the neighbor can be updated. If the >> larger packets don't make it to the neighbor there is no complexity >> and no delay: communication was already underway at 1500 bytes and >> continues without the need for further action. > Yep! I'd considered this, but at 3am didn't want to confuse the issue > by introducing too many differing ideas at the same time. (Also, I > wanted to go to sleep :) You've seemed to have thought through =20 > some of > the issues a bit better than I had too :) (-: >> However, this doesn't accommodate finding out jumboframe support at >> reduced sizes very well. For this, I think we should use an =20 >> additional >> exchange, but this one should probably happen over multicast. > I disagree. There is no need to for every host to have a full > understanding of the layer 2 topology of the network it is on. That's not what the mechanism that I outlined does. What it does do =20 is let all jumbo-capable system send send at least one packet at =20 their maximum size and get feedback on whether it was received by =20 anyone. For that, every packet may update information that the system =20= (host or router) holds, but then the old information is gone so there =20= is no per-(potential) correspondent state. > We're > starting to see some very large L2 networks as MAN's (eg NLR[1]) and > IPv6's /64 per subnet puts no real practical limit on how large a =20 > single > L2 segment can be. Hm, they invented routers for a reason, I don't think we have to bend =20= over backwards to accommodate unreasonably large layer 2 networks. =20 But: what would be reasonable to accommodate? 1000 systems? > Multicasting out "jumbo" packets is going to tax switch queue sizes to > the extreme. A 48 port switch, receiving a single multicast 9k packet > (that it can forward) may end up with 48*9k=3D430,000 bytes (or =20 > nearly 1/2 > a megabyte) of buffer space used with a single packet arriving. I'm not sure this is a problem: as far as I know (and that's not too =20 far) switches use per-port buffer space, so although such a packet =20 uses up buffer space for a lot of ports, there is nothing =20 unreasonable about that (packet is gone again in 72 microseconds =20 anyway). But some vendor feedback would be good here. > What happens on l2's where not every node can see every other node? Neighbor discovery fails? > Some L2's only allow end hosts to talk to a master host. What about a > network with vlans where some hosts are on differing sets of vlans? I don't think those exist in that way. >> A C >> | | >> +-+--+ +----+ +--+-+ >> |9000+--+3000+--+8000| >> +-+--+ +----+ +--+-+ >> | | >> B D > If A and B are talking to each other and C and D are talking to each > other, why do (A and B) need to talk to C and D? Ah, but how do you know that A doesn't talk to D, and is never going to? > Why not a simpler protocol? > Host A sends a ND to Host B with Host A's MRU. > Host B replies with a NS to Host A with Host B's MRU. > Host A can now start transmitting the data it wants to send. > Host A now sends Host B a ICMP MTU Probe, at some size less than or > equal to Host B's MRU > If Host B receives the packet, it replies with an ICMP MTU Probe reply > saying what it received. The problem here is that if the switches in the middle don't support =20 jumboframe sizes A and B do, you can't use jumboframes at all. Since =20 there is no standard jumboframe size, this is a problem. Of course A =20 and B can discover the maximum size between them, but doing that =20 between any set of correspondents seems suboptimal. On the other hand, if we reuse the information learned for previous =20 correspondents, this could work well. So: When ND indicates a neighbor supports jumboframes, we start by =20 sending an MTU prope with either an MTU that worked towards another =20 correspondent fairly recently (last hour or so). If the correspondent =20= receives this packet it sends an ack and both sides can increase the =20 MTU. However, it's possible we can improve on this MTU, so now we do a =20 binary search between the current MTU and the maximum usable one (=3D =20= minimum of local and remote MTU/MRUs), at one packet per second or so. If the first probe with a recently used MTU fails then we do a binary =20= search betwen that value and an initial one, which should probably be =20= 1508 (some NICs don't do jumboframes but support 1504 for VLAN use, =20 nearly all MTUs are 32 bit aligned, the maximum 3 extra bytes aren't =20 worth it anyway). I think we can assume the MTU is the same in both directions. So when =20= system A tries with 3000 bytes (worked with C!) towards B, B sets an =20 ack flag and tries with 9216, which fails, so A sends a NAK and tries =20= with 6108, and so on. With each successful packet (either received or =20= acknowledged) the MTU towards the correspondent can be increased =20 immediately. > By working "up" known sizes instead of doing a binary search (or =20 > working > down), Host A can quickly ratchet up sizes without waiting for a =20 > timeout > gaining immediate benefits from larger MTUs as they are discovered. You can do this with binary search too, as long as you send a =20 separate "now testing YYYY, ack XXXX" packet. I don't think we want to do this at top speed, though, because the =20 control traffic could get in the way of real traffic. > If you persist with this idea, switch the order of the packets sent. > Send the packet first, then send the announcement that it was sent. Yes, that makes sense. I thought there would be a possibility that =20 the switch or hub would need some time to recover after receiving a =20 packet that's too large, though. > Assuming no reordering you then don't have to wait for a timeout. If > reordering does occur you then send a "Whoops! reordering! didn't =20 > expect > that on the same L2!" and then everyone flags that interface as > "possible reordering" and then always waits for a timeout. > In the common case of no reordering this will be much faster due to =20= > not > waiting for timeouts. If the "I sent..." packet comes in before the actual test packet, =20 then this would look like the test packet didn't make it, so the =20 receiver would send a NAK. However, if the packet does make it and =20 comes in late, then obviously the receiver notices this and it can =20 send out an ACK as well. Since we don't want to hammer the layer 2 =20 network with possibly invalid packets, the receiver (well, sender of =20 the original probe) would probably want to wait long enough for that =20 ACK to come in before sending the next packet anyway. > Not everything has a MAC address. Yikes! You really are a modern day Ren=E9 Descartes, aren't you? :-) > Difference in link local addresses? > This sounds very much like turning Ethernet into token ring . Ring networks are very cool, too bad we don't have them anymore. >> Alternatively, we could add an RA option that administrators can =20 >> use to >> tell hosts the jumboframe size the layer 2 network supports. (The RA >> option doesn't say anything about the capabilities of the _router_.) >> Then the whole multicast taking turns discovery isn't necessary, =20 >> and we >> can suffice with a quick one-to-one verification before =20 >> jumboframes are >> used. > This still seems to fall foul of either requiring the administrator to > configure the router Well, that's what administrators do, isn't it? > or degrading the entire network to the level of the > router. No, the announcement "the switch can handle 4500 bytes" wouldn't have =20= anything to do with "I can handle 1500". It's probably a good idea to make announcements like this part of the =20= protocol, but not as RA options. That way, switches can announce =20 their own MTU capabilities, even if they don't otherwise support =20 IPv6. So if the switch says that it can do 4500, we only have to try =20 4500 (ack) and 4504 (nak) and everything is much faster. (Unless the =20 layer 2 network is more complex, of course, but then either 4500 gets =20= a nack/timeout or 4504 gets an ack.) Hm, maybe 4 bytes larger than an earlier maximum is always a good =20 idea... It would be even better if we could ask the switch what our port =20 supports, but I'm not sure how to do this in such a way that a switch =20= that doesn't support this protocol floods the request so the results =20 are meaningless.= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 25 03:35:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwxUi-0006vB-FG; Mon, 25 Jul 2005 03:35:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwxUc-0006v3-RJ for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 03:35:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23743 for ; Mon, 25 Jul 2005 03:35:17 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwxzM-0006ql-2B for ipv6@ietf.org; Mon, 25 Jul 2005 04:07:09 -0400 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 88B8B15218; Mon, 25 Jul 2005 16:34:51 +0900 (JST) Date: Mon, 25 Jul 2005 16:34:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Samita Chakrabarti In-Reply-To: <200507230019.j6N0JJMx741705@jurassic.eng.sun.com> References: <200507230019.j6N0JJMx741705@jurassic.eng.sun.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipv6@ietf.org, erik.nordmark@sun.com, keiichi@iijlab.net, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 22 Jul 2005 17:18:20 -0700 (PDT), >>>>> Samita Chakrabarti said: > The idea is to use both IPV6_PREFER flags in conjunction with corresponding > AI_PREFER_* flags in getaddrinfo(). > RFC3484 Destination address selection rule #8 ( prefer smaller scope): > Thus, IPV6_PREFER_DST_SMALLSCOPE is the default setting for a system. > One example might be that if sender wants to use global destination > address to talk to an onlink node for which it knows a smaller scope > address. In that situation, setting LARGESCOPE > socket option and passing AI flag to getaddrinfo() is recommended. For which socket are you intending to set the LARGESCOPE socket option? Could you show an example code fragment that uses this option (e.g., containing calls to getaddrinfo(), socket(), and connect() or sendto())? > Now, for DST flags, it may be possible to get away with AI_PREFER_* flags, > but, implementations may vary in implementing getaddrinfo() for collecting > potential source addresses (RFC3484 section 8). > Hence for portability and consistency reason, both setsockopt() and AI flags > are recommended for destination scope. > From implementation point of view do you think IPV6_PREFER_DST_*SCOPE > is redundant across all systems ? I don't know about "all" systems, but I cannot just imagine meaningful usage for this option. And, if no one can provide concrete useful usage, I don't think it a good idea to provide such a meaningless option just for "consistency". 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 Jul 25 06:03:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwznZ-0006jX-Hy; Mon, 25 Jul 2005 06:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwznW-0006jS-QK for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 06:02:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02741 for ; Mon, 25 Jul 2005 06:02:56 -0400 (EDT) Received: from yamaha-ctcnetlink14.yamaha.co.jp ([218.216.190.126] helo=aphrodite.comm.yamaha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx0IL-00039G-16 for ipv6@ietf.org; Mon, 25 Jul 2005 06:34:50 -0400 Received: from aphrodite.comm.yamaha.co.jp by aphrodite.comm.yamaha.co.jp via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Mon, 25 Jul 2005 19:02:56 +0900 Received: from localhost (selene [133.176.112.13]) by comm.yamaha.co.jp (8.12.11/8.9.3/CY01) with ESMTP id j6PA2M0K046555; Mon, 25 Jul 2005 19:02:23 +0900 (JST) (envelope-from hirose@comm.yamaha.co.jp) Date: Mon, 25 Jul 2005 19:02:09 +0900 (JST) Message-Id: <20050725.190209.179824639.hirose@comm.yamaha.co.jp> To: ipv6@ietf.org From: Ryota Hirose In-Reply-To: <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> References: <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, >From: Bob Hinden >Date: Fri, 22 Jul 2005 13:18:24 -0700 > In my personal view, having devices on shared media with different MTU's is > just a bad idea. I think so, but in a real world, such bad ideas are often accepted. In the IPv4 environment, MTU problem is more simple because DHCP has no MTU option. The mechanisms to adjust packet size are PMTUD and TCP MSS negotiation. For TCP applications to the Internet, these mechanisms will work fine. For UDP or ICMP applications to the Internet, almost applications restrict a packet size less than 1500. Of course, NFS uses large packet size, but almost people will not use NFS over the Internet. So, people can use the Internet fine, and enjoy Jumbo Frames in LAN. To make a same situation for IPv6, we must not include MTU option in RA. An interoperability will be down slightly, but we can use Jumbo Frames. If RA includes MTU option, we will get a perfect interoperability about MTU, but cannot use Jumbo Frame. Now, people are accumulating the knowledge about Jumbo Frames. They will learn the trick to use Jumbo Frames for IPv4, and will say, "IPv6 is slower than IPv4, because it disables Jumbo Frames...". I think there are three ways for us. 1) Do nothing. Jumbo Frames is an illegal specification for IEEE 802.3, and there is no de facto frame size also. Wait until IEEE will move, or a de facto standard will be made. 2) Make a new protocol for MTU/MRU discovery/negotiation. Thanks for Mark, Iljitsch or others. 3) Make a memorandum for Jumbo Frames with current implementations. Fix the implicit maximum value of RFC2464, how to enable Jumbo Frames for IPv6, the estimated problems, the implimentation restrictions, and so on. Ryota Hirose Yamaha Corporation -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 25 07:23:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx13i-00054i-CI; Mon, 25 Jul 2005 07:23:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx13f-00054R-3a; Mon, 25 Jul 2005 07:23:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07941; Mon, 25 Jul 2005 07:23:42 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx1YU-0005oy-A5; Mon, 25 Jul 2005 07:55:35 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2005 07:23:32 -0400 X-IronPort-AV: i="3.95,139,1120449600"; d="scan'208"; a="63766996:sNHT33259430" 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 j6PBNVVu017799; Mon, 25 Jul 2005 07:23:31 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 07:23:38 -0400 Received: from 10.86.243.3 ([10.86.243.3]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Mon, 25 Jul 2005 11:23:30 +0000 Received: from localhost.localdomain by email.cisco.com; 25 Jul 2005 11:24:13 +0000 From: Ralph Droms To: Tim Chown In-Reply-To: <20050725104526.GB24355@login.ecs.soton.ac.uk> References: <8E296595B6471A4689555D5D725EBB2164F0C6@xmb-rtp-20a.amer.cisco.com> <20050725104526.GB24355@login.ecs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 25 Jul 2005 07:24:12 -0400 Message-Id: <1122290653.8552.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 25 Jul 2005 11:23:38.0719 (UTC) FILETIME=[4DE10EF0:01C5910B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , Robert Hinden , soohong.park@samsung.com, dhcwg@ietf.org, syam@samsung.com, ipv6@ietf.org, jinmei@isl.rdc.toshiba.co.jp Subject: Re: [dhcwg] Re: Draft agenda X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Tim - my memory is also that the discussion tapered off without a conclusion. I do remember getting a summary e-mail from Bob and Brian (ipv6 WG chairs) about "no consensus for changing M/O bits at this point" (but I can't locate that e-mail); however, my memory of the discussion is that there were two interleaved discussions: (1) improve documentation of what was in the RFC 246[012] specs and (2) consider changes (improvements) to spec for M/O bits and DHCPv6. So, I'm unclear about any conclusions... I've included the ipv6 WG chairs and the authors of draft-ietf-ipv6-ra- mo-flags-01.txt in the CC: list; can any of you clarify the resolution of the discussion, and should the discussion appear on the ipv6 or dhc (or both) WG agendas? - Ralph On Mon, 2005-07-25 at 11:45 +0100, Tim Chown wrote: > On Sat, Jul 23, 2005 at 09:38:21PM -0400, Bernie Volz (volz) wrote: > > Also, what's happened with the M/O bit discussion? Has this been > > resolved in the IPv6 WG or are they expecting us to do anything? Should > > that be an agenda item? > > I think it should, at least briefly. > > My recollection is that the discussion fizzled out without a conclusion. > > There is a specifc (newish) draft on the topic: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ra-mo-flags-01.txt > > I'm not sure how strong consensus is on the contents of this draft. > > One of the issues was that there are two bits, with four combinations, > one of which is 'meaningless'. But then an administrator should never > use that combination. People still seem to see some 'confusion' in > the semantics. While questions keep hitting the ipv6 list, one can argue > that the M/O text is certainly not as clear/streamlined as it could be. > > Some argued whether a DHC service indication was needed at all. Just let > the client back off. One question was over unecessary use of > bandwidth/battery on low capacity wireless devices - a hint that no DHC > was available would then be useful rather than the client retrying. > > There were some interesting ideas, e.g. that perhaps all stateless DHC > servers could respond to the same message types as stateful - I think the > JOIN people suggested that. Presumably you'd then only need the M bit, > given M and O semantics were being ushered towards the message type. > > I don't like the idea of changing things now without larger deployment > experience, and I recall most people agreed that was lacking. > > Anyway, Ralph/Stig should maybe check that the topic is on the ipv6 WG > agenda and take it from there, since ipv6 is held on Tuesday and dhc is > on Thursday. > > Tim > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 25 07:56:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx1Z5-0004DE-GA; Mon, 25 Jul 2005 07:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx1Z3-0004D5-Sn for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 07:56:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10758 for ; Mon, 25 Jul 2005 07:56:09 -0400 (EDT) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx23r-0007FA-Hc for ipv6@ietf.org; Mon, 25 Jul 2005 08:28:02 -0400 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Mon, 25 Jul 2005 11:56:04 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw11c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Mon, 25 Jul 2005 11:55:52 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Jul 2005 06:55:33 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9767B8@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Re: Proposed IPv6 W.G. Agenda for Paris Thread-Index: AcWRD8NLJgAYJ2VAT8+3zVPPE8lo1Q== From: "Pashby, Ronald W CTR NSWCDD-B35" To: , , X-OriginalArrivalTime: 25 Jul 2005 11:55:34.0142 (UTC) FILETIME=[C38F69E0:01C5910F] X-Spam-Score: 0.8 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org 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="===============0361110763==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0361110763== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5910F.C35E72A0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5910F.C35E72A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bob, I request the opportunity to present = draft-pashby-ipv6-network-discovery-00 and = draft-pashby-ipv6-detecting-spoofing-00. I will not be present but Karen = O'Donoghue is willing to present it for me. I believe these are = important issues and must be considered now before the ICMP and other = drafts go forward. Ron Pashby ------_=_NextPart_001_01C5910F.C35E72A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Proposed IPv6 W.G. Agenda for Paris

Bob,
I request the opportunity to present = draft-pashby-ipv6-network-discovery-00 and = draft-pashby-ipv6-detecting-spoofing-00. I will not be present but Karen = O'Donoghue is willing to present it for me. I believe these are = important issues and must be considered now before the ICMP and other = drafts go forward.

Ron Pashby

------_=_NextPart_001_01C5910F.C35E72A0-- --===============0361110763== 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 -------------------------------------------------------------------- --===============0361110763==-- From ipv6-bounces@ietf.org Mon Jul 25 08:03:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx1gU-0005pd-VU; Mon, 25 Jul 2005 08:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx1gR-0005oO-OH; Mon, 25 Jul 2005 08:03:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12254; Mon, 25 Jul 2005 08:03:46 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx2BE-0007nG-FX; Mon, 25 Jul 2005 08:35:39 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK600D3EMTQZ6@mailout1.samsung.com>; Mon, 25 Jul 2005 21:03:26 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IK600FU8MTA23@mmp1.samsung.com>; Mon, 25 Jul 2005 21:03:26 +0900 (KST) Date: Mon, 25 Jul 2005 17:29:07 +0530 From: Syam Madanapalli To: Ralph Droms , Tim Chown Message-id: <024201c59110$53f2c310$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <8E296595B6471A4689555D5D725EBB2164F0C6@xmb-rtp-20a.amer.cisco.com> <20050725104526.GB24355@login.ecs.soton.ac.uk> <1122290653.8552.30.camel@localhost.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7BIT Cc: Brian Haberman , Robert Hinden , soohong.park@samsung.com, dhcwg@ietf.org, jinmei@isl.rdc.toshiba.co.jp, ipv6@ietf.org Subject: Re: [dhcwg] Re: Draft agenda X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, We tried to summarize the discussion on M/O flags, but we (authors of the M/O flags) were busy with other things, so we could not do that. But from the discussion we found three different opinions 1. Leave M/O Flags unchanged 2. Flags independently represent DHCPv6 and DHCP lite (M-flag for HCB, O-Flag for ICB) 3. M-Flag (to hint) for triggering DHC (Remove O-flag) Even in the case of 1 we would like to put some text to clarify the flags usage. We are planning to trim draft-ietf-ipv6-ra- mo-flags-01.txt without policy variables. Also it may be worth to see what could be the impacts of case 2 and case 3 from DHCP perspective as well as from IPv6 perspective. If at we decide to change better to go for 3, otherwise just clarify them about their (M/O flags) usage and leave them as it is. Regards, Syam ----- Original Message ----- From: "Ralph Droms" To: "Tim Chown" Cc: "Robert Hinden" ; "Brian Haberman" ; ; ; ; ; Sent: Monday, July 25, 2005 4:54 PM Subject: Re: [dhcwg] Re: Draft agenda > Tim - my memory is also that the discussion tapered off without a > conclusion. > > I do remember getting a summary e-mail from Bob and Brian (ipv6 WG > chairs) about "no consensus for changing M/O bits at this point" (but I > can't locate that e-mail); however, my memory of the discussion is that > there were two interleaved discussions: (1) improve documentation of > what was in the RFC 246[012] specs and (2) consider changes > (improvements) to spec for M/O bits and DHCPv6. So, I'm unclear about > any conclusions... > > I've included the ipv6 WG chairs and the authors of draft-ietf-ipv6-ra- > mo-flags-01.txt in the CC: list; can any of you clarify the resolution > of the discussion, and should the discussion appear on the ipv6 or dhc > (or both) WG agendas? > > - Ralph > > > > On Mon, 2005-07-25 at 11:45 +0100, Tim Chown wrote: >> On Sat, Jul 23, 2005 at 09:38:21PM -0400, Bernie Volz (volz) wrote: >> > Also, what's happened with the M/O bit discussion? Has this been >> > resolved in the IPv6 WG or are they expecting us to do anything? Should >> > that be an agenda item? >> >> I think it should, at least briefly. >> >> My recollection is that the discussion fizzled out without a conclusion. >> >> There is a specifc (newish) draft on the topic: >> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ra-mo-flags-01.txt >> >> I'm not sure how strong consensus is on the contents of this draft. >> >> One of the issues was that there are two bits, with four combinations, >> one of which is 'meaningless'. But then an administrator should never >> use that combination. People still seem to see some 'confusion' in >> the semantics. While questions keep hitting the ipv6 list, one can argue >> that the M/O text is certainly not as clear/streamlined as it could be. >> >> Some argued whether a DHC service indication was needed at all. Just let >> the client back off. One question was over unecessary use of >> bandwidth/battery on low capacity wireless devices - a hint that no DHC >> was available would then be useful rather than the client retrying. >> >> There were some interesting ideas, e.g. that perhaps all stateless DHC >> servers could respond to the same message types as stateful - I think the >> JOIN people suggested that. Presumably you'd then only need the M bit, >> given M and O semantics were being ushered towards the message type. >> >> I don't like the idea of changing things now without larger deployment >> experience, and I recall most people agreed that was lacking. >> >> Anyway, Ralph/Stig should maybe check that the topic is on the ipv6 WG >> agenda and take it from there, since ipv6 is held on Tuesday and dhc is >> on Thursday. >> >> Tim >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 25 08:56:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx2Va-0003jP-VU; Mon, 25 Jul 2005 08:56:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx2VV-0003Zu-3r for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 08:56:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16483 for ; Mon, 25 Jul 2005 08:56:32 -0400 (EDT) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx30I-0001D6-PB for ipv6@ietf.org; Mon, 25 Jul 2005 09:28:26 -0400 Received: OTM-MO id j6PCuFWZ007166; Mon, 25 Jul 2005 21:56:15 +0900 (JST) Received: OTM-MIX0 id j6PCuEad018570; Mon, 25 Jul 2005 21:56:15 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j6PCuE6O021581; Mon, 25 Jul 2005 21:56:14 +0900 (JST) Date: Mon, 25 Jul 2005 21:56:23 +0900 (JST) Message-Id: <20050725.215623.25214583.keiichi@iijlab.net> To: jinmei@isl.rdc.toshiba.co.jp From: Keiichi SHIMA In-Reply-To: References: <200507230019.j6N0JJMx741705@jurassic.eng.sun.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: erik.nordmark@sun.com, ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Samita and Tatsuya, From: JINMEI Tatuya / $B?@L@C#:H(B Date: Mon, 25 Jul 2005 16:34:51 +0900 > >>>>> On Fri, 22 Jul 2005 17:18:20 -0700 (PDT), > >>>>> Samita Chakrabarti said: > > > The idea is to use both IPV6_PREFER flags in conjunction with corresponding > > AI_PREFER_* flags in getaddrinfo(). > > > RFC3484 Destination address selection rule #8 ( prefer smaller scope): > > > Thus, IPV6_PREFER_DST_SMALLSCOPE is the default setting for a system. > > > One example might be that if sender wants to use global destination > > address to talk to an onlink node for which it knows a smaller scope > > address. In that situation, setting LARGESCOPE > > socket option and passing AI flag to getaddrinfo() is recommended. > > For which socket are you intending to set the LARGESCOPE socket > option? Could you show an example code fragment that uses this option > (e.g., containing calls to getaddrinfo(), socket(), and connect() or > sendto())? I had the same feeling with Tatsuya. For the particular case, that you quated, maybe we don't need IPV6_PREFER_DST_ option. If were you, I would write the following code: hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_STREAM; hints.ai_flags = AI_PREFER_SRC_LARGESCOPE|AI_PREFER_DST_LARGESCOPE; getaddrinfo("www.foobar.com", "http", &hints, &res0); for every res in res0 { s = socket(res->ai_family, res->ai_socktype, res->ai_protocol); setsockopt(s, IPPROTO_IPV6, IPV6_PREFER_SRC_LARGESCOPE=on); connect(s, res->ai_addr, res->ai_addrlen); ... } I think specifying IPV6_PREFER_DST_XXX doesn't have any meaning, because the destination address has already been chosen in getaddrinfo(). > > Now, for DST flags, it may be possible to get away with AI_PREFER_* flags, > > but, implementations may vary in implementing getaddrinfo() for collecting > > potential source addresses (RFC3484 section 8). > > Hence for portability and consistency reason, both setsockopt() and AI flags > > are recommended for destination scope. I agree that AI_PREFER_DST_XXX is necessary to give a user a chance to choose preferred destination address based on the conditions you listed in the draft. > > From implementation point of view do you think IPV6_PREFER_DST_*SCOPE > > is redundant across all systems ? > > I don't know about "all" systems, but I cannot just imagine meaningful > usage for this option. And, if no one can provide concrete useful > usage, I don't think it a good idea to provide such a meaningless > option just for "consistency". --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 25 08:59:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx2Yn-0004sQ-2o; Mon, 25 Jul 2005 08:59:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx2Yi-0004i4-B7 for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 08:59:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16913 for ; Mon, 25 Jul 2005 08:59:51 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx33W-0001Mm-8i for ipv6@ietf.org; Mon, 25 Jul 2005 09:31:45 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6PCxrk0080004 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 25 Jul 2005 14:59:54 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20050725.190209.179824639.hirose@comm.yamaha.co.jp> References: <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> <20050725.190209.179824639.hirose@comm.yamaha.co.jp> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D358CFA-E59A-4C78-96E6-77274F54E89A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Mon, 25 Jul 2005 14:59:11 +0200 To: Ryota Hirose X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 25-jul-2005, at 12:02, Ryota Hirose wrote: >> In my personal view, having devices on shared media with different >> MTU's is >> just a bad idea. > I think so, but in a real world, such bad ideas are often accepted. :-) Thinking a bit more about this: ethernet rules the world right now, and I see few competitors on the horizon. Although an ethernet switch detects attachment to a port and even negotiates a few capabilities, there is no mechanism to furter distribute the information learned that way (if any), so the only way to be certain that all systems connected to an ethernet use the same MTU is by observing the 30 year old 1500 byte maximum, or by having an administrator police the MTU of all attached devices. In other words: the current situation, where jumboframe deployment is negligible. I think we have to turn this around and acknowledge that having a fixed MTU on any network (whatever the layer) stifles progress so we should embrace MTU diversity. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 25 14:23:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7cI-0000k7-Nk; Mon, 25 Jul 2005 14:23:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7cE-0000jm-Dn for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 14:23:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12168 for ; Mon, 25 Jul 2005 14:23:47 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx872-0003kX-MR for ipv6@ietf.org; Mon, 25 Jul 2005 14:55:44 -0400 Received: from jurassic.eng.sun.com ([129.146.106.105]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6PINgcn007940; Mon, 25 Jul 2005 11:23:42 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j6PINgHo317843; Mon, 25 Jul 2005 11:23:42 -0700 (PDT) Message-Id: <200507251823.j6PINgHo317843@jurassic.eng.sun.com> Date: Mon, 25 Jul 2005 11:22:40 -0700 (PDT) From: Samita Chakrabarti To: keiichi@iijlab.net, jinmei@isl.rdc.toshiba.co.jp MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: D29xAIAknkHSBjlEQmk+cA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: erik.nordmark@sun.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Keiichi, > > > > > One example might be that if sender wants to use global destination > > > address to talk to an onlink node for which it knows a smaller scope > > > address. In that situation, setting LARGESCOPE > > > socket option and passing AI flag to getaddrinfo() is recommended. > > > > For which socket are you intending to set the LARGESCOPE socket > > option? Could you show an example code fragment that uses this option > > (e.g., containing calls to getaddrinfo(), socket(), and connect() or > > sendto())? > > I had the same feeling with Tatsuya. > Thanks for providing the example below. It is similar to what I had in mind. I agree that setting IPV6_PREFER_DST socket option may be redundant in most implementations. I can see your and Jinmei's view point. > For the particular case, that you quated, maybe we don't need > IPV6_PREFER_DST_ option. If were you, I would write the following code: > > hints.ai_family = PF_UNSPEC; > hints.ai_socktype = SOCK_STREAM; > hints.ai_flags = AI_PREFER_SRC_LARGESCOPE|AI_PREFER_DST_LARGESCOPE; > getaddrinfo("www.foobar.com", "http", &hints, &res0); > for every res in res0 { > s = socket(res->ai_family, res->ai_socktype, res->ai_protocol); > setsockopt(s, IPPROTO_IPV6, IPV6_PREFER_SRC_LARGESCOPE=on); > connect(s, res->ai_addr, res->ai_addrlen); > ... > } > > I think specifying IPV6_PREFER_DST_XXX doesn't have any meaning, > because the destination address has already been chosen in > getaddrinfo(). > Are you suggesting to drop all the IPV6_PREFER_DST_*SCOPE socket-option flags ? I'll discuss this with my co-authors of this draft. Does any implementor in this list have any objection on dropping the above socket option? Thanks again, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 25 15:52:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx90G-0001gW-JZ; Mon, 25 Jul 2005 15:52:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx90E-0001gP-VC for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 15:52:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18864 for ; Mon, 25 Jul 2005 15:52:41 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx9V7-0006OS-Gq for ipv6@ietf.org; Mon, 25 Jul 2005 16:24:40 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6PJLEs02810; Mon, 25 Jul 2005 12:21:14 -0700 X-mProtect: <200507251921> Nokia Silicon Valley Messaging Protection Received: from danira-pool048138.americas.nokia.com (10.241.48.138, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdohbvYA; Sat, 23 Jul 2005 16:42:33 PDT Message-Id: <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 23 Jul 2005 17:17:25 -0700 To: Iljitsch van Beijnum From: Bob Hinden In-Reply-To: References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Iljitsch, At 05:57 PM 07/22/2005, Iljitsch van Beijnum wrote: >On 22-jul-2005, at 22:18, Bob Hinden wrote: > >>In my personal view, having devices on shared media with different >>MTU's is just a bad idea. Trying to get it to work is complicated >>and I think it will have lots of nasty failure cases. If one wants >>to have mixed speeds (like the example above) then use the default >>MTU (i.e., 1500) or replace the GbE-Switch with a Router. If one >>wants Jumbo Frames, then make sure all of the nodes on the link >>support 1000Base-T. > >Unfortunately 1000baseT (is that the correct designation?) doesn't >equal jumboframe capability, so the problem remains. Right, I don't know what the correct designation is either. >Don't forget that management issues in layer 2 networks (= a single >layer 3 subnet) are very different from those on the global internet: >most layer 2 networks are managed by a single organization. Since we >had the hubris to think we could do PMTUD for the global internet, I >think we shouldn't shy away from doing the same thing for layer 2. As >always, the operator community will decide wheter what we come up >with is usable in practice. Fair point. As suggested on the list a new NA/NS option seems like a reasonable approach except for the problems pointed out. Having to do probes of different packet sizes is fairly messy if there is a device in the middle with a smaller MTU. Would a NA/NS option solution solve enough of the problem to make doing it worthwhile? Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 25 16:58:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxA22-0007rc-Mr; Mon, 25 Jul 2005 16:58:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxA20-0007rX-LA for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 16:58:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22966 for ; Mon, 25 Jul 2005 16:58:34 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxAWs-0008OK-Sr for ipv6@ietf.org; Mon, 25 Jul 2005 17:30:34 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA05363; Mon, 25 Jul 2005 15:58:04 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6PKw2s06986; Mon, 25 Jul 2005 13:58:02 -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.211); Mon, 25 Jul 2005 13:58:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Jul 2005 13:58:01 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4F56@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: jumbo frame of GbE and IPv6 Thread-Index: AcWO8LYqB/n+Lk7PRYm53CUw6nBEXACZnTGg From: "Templin, Fred L" To: "Fred Baker" , "Stephen Sprunk" X-OriginalArrivalTime: 25 Jul 2005 20:58:02.0188 (UTC) FILETIME=[8BB518C0:01C5915B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Fred,=20 =20 > The suggestion actually comes from Matt's document, I just=20 > pointed it =20 > out and suggested a simple first-burst implementation. > http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-04.txt > "Path MTU Discovery", Matt Mathis, 22-Feb-05 Section 4.2 of: 'draft-templin-ipvlx-02.txt' proposes a link adaptation method for tunnels that uses a probing strategy similar to what is described in 'draft-ietf-pmtud-method-04.txt' and also observes most of the tunnel MTU/MRU determination rules specified in section 3 of 'draft-ietf-v6ops-mech-v2-07.txt'. The proposal supports GbE jumbo frame MTUs on a per-decapsulator basis and also allows host-based segmentation for sending the larger packets when the decapsulator can accept jumbo frames but some L2 switch on the path cannot. This is being mentioned for the sake of providing completeness to this discussion, since it addresses the case of tunnels being used instead of native IPv6 in some deployment scenarios. Although I cannot give a schedule, the document is due for an update after the I-D repository re-opens following IETF63. 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 Mon Jul 25 18:00:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxAzu-0004MN-Nb; Mon, 25 Jul 2005 18:00:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxAzt-0004M8-0Q for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 18:00:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26901 for ; Mon, 25 Jul 2005 18:00:26 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxBUn-0001jH-OQ for ipv6@ietf.org; Mon, 25 Jul 2005 18:32:27 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6PM12k0088679 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 26 Jul 2005 00:01:03 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84337651-4295-4FFA-BEE1-3B9ADD5FB103@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Tue, 26 Jul 2005 00:00:20 +0200 To: Bob Hinden X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 24-jul-2005, at 2:17, Bob Hinden wrote: >> Don't forget that management issues in layer 2 networks (= a single >> layer 3 subnet) are very different from those on the global internet: >> most layer 2 networks are managed by a single organization. Since we >> had the hubris to think we could do PMTUD for the global internet, I >> think we shouldn't shy away from doing the same thing for layer 2. As >> always, the operator community will decide wheter what we come up >> with is usable in practice. > Fair point. As suggested on the list a new NA/NS option seems like > a reasonable approach except for the problems pointed out. Having > to do probes of different packet sizes is fairly messy if there is > a device in the middle with a smaller MTU. Would a NA/NS option > solution solve enough of the problem to make doing it worthwhile? If in a conservative approach we don't want to send "jumboprobes" we still need an easy way to let the hosts know the limits of the infrastructure. A packet that is multicast by systems "in the know" would do the trick. Since the most obvious source of knowledge would be switches, it makes sense to make it easy for a switch to multicast this information, which means it shouldn't be part of RAs as switches as a rule don't send those out. (If we make the message very simple and let the switch use the unspecified address as a source address, there wouldn't be any need for the switch to run IPv6, it would just transmit a fixed content packet.) In the absense of "smart" switches, one or more routers or even hosts could be configured to send out proxy jumboframe size announcements. When a host hears multiple jumboframe sizes announced, it would select the smallest it hears. To avoid the situation where there is a smart switch that announces a jumboframe size and also a stupid switche that doesn't, and also don't support jumboframes (of that size), or the situation where an administrator makes a mistake, it would still be necessary to confirm that the advertised MTU size is correct by sending an MTU sized jumboframe after an ND option indicates that a neighbor supports jumboframes. This approach still provides most of what we'd like, except that all systems share the same effective MTU, which they learn from an administratively configured value, and hopefully in the future, directly from the layer 2 infrastructure. What do you think? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jul 25 22:41:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFOF-0001J6-VK; Mon, 25 Jul 2005 22:41:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFOE-0001J1-Kz for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 22:41:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15626 for ; Mon, 25 Jul 2005 22:41:52 -0400 (EDT) Received: from smta10.mail.ozemail.net ([203.103.165.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxFtC-0001e7-Gf for ipv6@ietf.org; Mon, 25 Jul 2005 23:13:55 -0400 Received: from ubu.nosense.org ([210.84.225.248]) by smta10.mail.ozemail.net with ESMTP id <20050726024145.NQOW18072.smta10.mail.ozemail.net@ubu.nosense.org>; Tue, 26 Jul 2005 02:41:45 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id CB5E862AAE; Tue, 26 Jul 2005 12:11:43 +0930 (CST) Date: Tue, 26 Jul 2005 12:11:43 +0930 From: Mark Smith To: Bob Hinden Message-Id: <20050726121143.53648467.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; 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.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: iljitsch@muada.com, ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Bob, Iljitsch, On Sat, 23 Jul 2005 17:17:25 -0700 Bob Hinden wrote: > Iljitsch, > > At 05:57 PM 07/22/2005, Iljitsch van Beijnum wrote: > >On 22-jul-2005, at 22:18, Bob Hinden wrote: > > > >>In my personal view, having devices on shared media with different > >>MTU's is just a bad idea. Trying to get it to work is complicated > >>and I think it will have lots of nasty failure cases. If one wants > >>to have mixed speeds (like the example above) then use the default > >>MTU (i.e., 1500) or replace the GbE-Switch with a Router. If one > >>wants Jumbo Frames, then make sure all of the nodes on the link > >>support 1000Base-T. > > > >Unfortunately 1000baseT (is that the correct designation?) doesn't > >equal jumboframe capability, so the problem remains. > > Right, I don't know what the correct designation is either. > > >Don't forget that management issues in layer 2 networks (= a single > >layer 3 subnet) are very different from those on the global internet: > >most layer 2 networks are managed by a single organization. Since we > >had the hubris to think we could do PMTUD for the global internet, I > >think we shouldn't shy away from doing the same thing for layer 2. As > >always, the operator community will decide wheter what we come up > >with is usable in practice. > > Fair point. As suggested on the list a new NA/NS option seems like a > reasonable approach except for the problems pointed out. Having to do > probes of different packet sizes is fairly messy if there is a device in > the middle with a smaller MTU. Would a NA/NS option solution solve enough > of the problem to make doing it worthwhile? > I'd like to suggest a two phased development approach, based on whether layer 2 can be assumed to fully support the larger MTUs or not (I think the following is also probably a summary of the couple of threads of discussion in the emails of the last couple of days) : (1) Making the assumption that layer 2 can support larger, non-standard MTUs (as it has been engineered to by a network designer), develop mechanisms that allow nodes to announce their non-standard, larger MTU support. If a pair of nodes find they both support larger MTUs/MRUs, then they'll take advantage of it for unicast traffic. If the unicast communcations fails because layer 2 doesn't support the MTU/MRUs it is supposed to, then layer 2 is broken and it is up to network admin to fix it. In all other cases (eg. multicast, unicast without these announcements), the MTU used will be the either the link layer MTU standard or the link MTU value as announced in RAs (i.e., along the lines that this MTU value has been announced because the link layer technology doesn't have a standard value e.g. token ring. There is a corner case that needs to be covered where a larger than standard MTU has been annnounced for a technology that does have a fixed MTU e.g. 1500 byte ethernet, and a sub-set of nodes only support the standard size). These mechasims only come into play if non-standard MTU support has been enabled (in some mechanism specific manner, which may be via a new RA option, or even just configuring larger, non-standard MTUs on the interfaces that are capable of larger frames). The out-of-the-box plug-and-play IPv6 functionality that exists today will be preserved if these mechanisms aren't enabled, by all nodes using the link standard MTU or RA announced MTU. I think this solution would be relatively quick and simple to develop, and is applicable to any networks that have been specifically designed to support larger, non-standard MTUs. (2) Develop mechansisms that can dynamically discover MTU/MRU sizes, limitations and variations over time, including within intermediary layer 2 devices e.g., switches. It seems that some solutions have already started to be developed in this area, including the email discussion between Iljitsch and Perry, Matt Mathis in draft-ietf-pmtud-method-04.txt and Fred Templin in draft-templin-ipvlx-02.txt. If the above phased approach is followed, I think it would be useful to allow any ND or other options developed for phase 1 to be re-used for a phase 2 solution if they can. Any thoughts on this approach ? 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 Jul 25 22:55:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFbL-0003x7-9v; Mon, 25 Jul 2005 22:55:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFbJ-0003x2-VF for ipv6@megatron.ietf.org; Mon, 25 Jul 2005 22:55:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16581 for ; Mon, 25 Jul 2005 22:55:24 -0400 (EDT) Received: from zorg.st.net.au ([203.16.233.9] helo=borg.st.net.au ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxG6H-0001zL-FY for ipv6@ietf.org; Mon, 25 Jul 2005 23:27:26 -0400 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id 9A1D739498B for ; Tue, 26 Jul 2005 12:55:36 +1000 (EST) Received: from anchovy.zoic.org (static-2.241.240.220.dsl.comindico.com.au [220.240.241.2]) by borg.st.net.au (Postfix) with ESMTP id 204DA394987 for ; Tue, 26 Jul 2005 12:55:36 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id 0D86B7007F6; Tue, 26 Jul 2005 12:55:10 +1000 (EST) Date: Tue, 26 Jul 2005 12:55:10 +1000 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Message-ID: <20050726025510.GA31212@zoic.org> Mail-Followup-To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-URL: http://zoic.org/sharkey/ User-Agent: Mutt/1.5.9i X-Scanned-By: AMaViS-ng at borg.st.net.au X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Optimistic DAD Status X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org G'day all, As some of you might have noticed, Optimistic DAD is currently in "AD Followup", having got one "Discuss" in the IESG evaluation. You can find the details at: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11651&rfc_flag=0 I'm in the process of preparing a version -06 to address the comments by Thomas, Spencer and Bert/Jari. I'd just like to ask that anyone with other comments get them to me as soon as possible so they can be included. (Jari, if you could get in touch to help clarify a couple of things, that'd be great.) I won't be able to make it to this session, but I hope you all have fun in Paris! -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 00:54:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxHSE-0000Sf-OA; Tue, 26 Jul 2005 00:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxHSA-0000Ra-HZ for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 00:54:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23614 for ; Tue, 26 Jul 2005 00:54:03 -0400 (EDT) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxHx8-00059K-Pb for ipv6@ietf.org; Tue, 26 Jul 2005 01:26:08 -0400 Received: OTM-MO id j6Q4roio024848; Tue, 26 Jul 2005 13:53:51 +0900 (JST) Received: OTM-MIX0 id j6Q4roDL017491; Tue, 26 Jul 2005 13:53:50 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j6Q4rnmx026530; Tue, 26 Jul 2005 13:53:49 +0900 (JST) Date: Tue, 26 Jul 2005 13:54:01 +0900 (JST) Message-Id: <20050726.135401.24678637.keiichi@iijlab.net> To: Samita.Chakrabarti@eng.sun.com From: Keiichi SHIMA In-Reply-To: <200507251823.j6PINgHo317843@jurassic.eng.sun.com> References: <200507251823.j6PINgHo317843@jurassic.eng.sun.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: julien.ietf@laposte.net, erik.nordmark@sun.com, ipv6@ietf.org, jinmei@isl.rdc.toshiba.co.jp Subject: Re: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-03.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Samita, From: Samita Chakrabarti Date: Mon, 25 Jul 2005 11:22:40 -0700 (PDT) > > > > I think specifying IPV6_PREFER_DST_XXX doesn't have any meaning, > > because the destination address has already been chosen in > > getaddrinfo(). > > Are you suggesting to drop all the IPV6_PREFER_DST_*SCOPE socket-option > flags ? I'll discuss this with my co-authors of this draft. Yes, that is what I meant. > Does any implementor in this list have any objection on dropping > the above socket option? Though I only know the internal implementation of BSD networking systems, at least we don't need those socket options (related to choosing a destination address) for the BSD systems. I don't know other implementations. I'm not sure if there are any implementations which can utilize those socket options. I think inputs from other implementors should be helpful. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 01:29:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxI0C-0007XO-WC; Tue, 26 Jul 2005 01:29:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxI0A-0007XH-6K for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 01:29:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25671 for ; Tue, 26 Jul 2005 01:29:13 -0400 (EDT) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxIV8-00062z-I4 for ipv6@ietf.org; Tue, 26 Jul 2005 02:01:16 -0400 Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net [16.92.1.76]) by palrel13.hp.com (Postfix) with ESMTP id A66FB1C06D4B; Mon, 25 Jul 2005 22:29:05 -0700 (PDT) Received: from cacexc06.americas.cpqcorp.net ([16.92.1.28]) by cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 22:28:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Jul 2005 22:28:36 -0700 Message-ID: <83AB0942FD087D499DF2DD5CEE1B61330214C257@cacexc06.americas.cpqcorp.net> Thread-Topic: jumbo frame of GbE and IPv6 Thread-Index: AcWRGM0wcQRzbVYARn+yOh5p/QrfWQAiT1Mg From: "Ghanwani, Anoop" To: "Iljitsch van Beijnum" , "Ryota Hirose" X-OriginalArrivalTime: 26 Jul 2005 05:28:38.0825 (UTC) FILETIME=[E090E990:01C591A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org =20 > Thinking a bit more about this: ethernet rules the world=20 > right now, and I see few competitors on the horizon. Although=20 > an ethernet switch detects attachment to a port and even=20 > negotiates a few capabilities, there is no mechanism to=20 > furter distribute the information learned that way (if any),=20 > so the only way to be certain that all systems connected to=20 > an ethernet use the same MTU is by observing the 30 year old=20 > 1500 byte maximum, or by having an administrator police the=20 > MTU of all attached devices. In other words: the current=20 > situation, where jumboframe deployment is negligible. Sticking to 1500 bytes doesn't guarantee that everything will work with Ethernet. For example, there's new stuff going on IEEE 802.3 which extends the Ethernet frame size to accommodate additional headers such as VLAN tag and security headers. The payload size does still stay at 1500. However if you have the following scenario: [new host] <-> [new bridge] <-> [old bridge] <-> [new bridge] you could easily have a situation where the 1500 bytes + new headers is greater than what the old bridge can handle. It's a bit of a corner case, but nevertheless one that=20 we need to be aware of. Anoop -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 04:42:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxL0l-0006Dz-2V; Tue, 26 Jul 2005 04:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxL0i-0006Bn-Ln for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 04:42:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28556 for ; Tue, 26 Jul 2005 04:41:56 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx3.orcon.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxLVh-0003DR-6B for ipv6@ietf.org; Tue, 26 Jul 2005 05:14:02 -0400 Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx3.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j6Q8hpVe009592 for ; Tue, 26 Jul 2005 20:43:51 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1DxL0N-0005uL-00 for ; Tue, 26 Jul 2005 20:41:39 +1200 Message-ID: <42E5F743.2000506@coders.net> Date: Tue, 26 Jul 2005 20:41:39 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050724 X-Accept-Language: en-nz, en MIME-Version: 1.0 CC: ipv6@ietf.org References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> <20050726121143.53648467.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050726121143.53648467.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/993/Tue Jul 26 19:28:36 2005 on dbmail-mx3.orcon.net.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > I'd like to suggest a two phased development approach, based on whether > layer 2 can be assumed to fully support the larger MTUs or not (I think > the following is also probably a summary of the couple of threads of > discussion in the emails of the last couple of days) : > > (1) Making the assumption that layer 2 can support larger, non-standard > MTUs (as it has been engineered to by a network designer), develop > mechanisms that allow nodes to announce their non-standard, larger MTU > support. If a pair of nodes find they both support larger MTUs/MRUs, > then they'll take advantage of it for unicast traffic. If the unicast > communcations fails because layer 2 doesn't support the MTU/MRUs it is > supposed to, then layer 2 is broken and it is up to network admin to > fix it. It's difficult to say what MTU L2 should support. If you have a GigE link then you might assume 9k MTU's (which varient of 9k?), and the remote end also might have GigE, but there is a 100mbit switch in the middle preventing communication between both ends to use 9k MTU's. You can barely assume 1500 as people tend to tunnel things, you can get technologies like vlans, 802.1x or mpls eating heavily into your mtu. You should assume 1280 bytes and hope that you can raise it. More and more end users aren't qualified network admins, they are people who plug device A into device B and expect everything to "just work". Given how many PMTU failures you see on the production internet today, assuming even qualified network admins have the time and resources to debug current MTU mismatches seems unlikely let alone future ones. Any system which requires admin intervention to work IMHO will be a dismal failure. > In all other cases (eg. multicast, unicast without these announcements), > the MTU used will be the either the link layer MTU standard or the link > MTU value as announced in RAs (i.e., along the lines that this MTU value > has been announced because the link layer technology doesn't have a > standard value e.g. token ring. There is a corner case that needs to be > covered where a larger than standard MTU has been annnounced for a > technology that does have a fixed MTU e.g. 1500 byte ethernet, and a > sub-set of nodes only support the standard size). For multicast it seems wise to just "give up" and use 1280. Even if you can determine the MTU of all nodes in a multicast group, there are no assurances that it is going to remain stable and changes are much harder to deal with than the unicast case. Maybe allow an admin to tune this higher if they want to. > These mechasims only come into play if non-standard MTU support has been > enabled (in some mechanism specific manner, which may be via a new RA > option, or even just configuring larger, non-standard MTUs on the > interfaces that are capable of larger frames). The out-of-the-box > plug-and-play IPv6 functionality that exists today will be preserved if > these mechanisms aren't enabled, by all nodes using the link standard MTU > or RA announced MTU. > I think this solution would be relatively quick and simple to develop, > and is applicable to any networks that have been specifically designed > to support larger, non-standard MTUs. > > (2) Develop mechansisms that can dynamically discover MTU/MRU sizes, > limitations and variations over time, including within intermediary > layer 2 devices e.g., switches. It seems that some solutions have > already started to be developed in this area, including the email > discussion between Iljitsch and Perry, Matt Mathis in > draft-ietf-pmtud-method-04.txt and Fred Templin in > draft-templin-ipvlx-02.txt. > > If the above phased approach is followed, I think it would be useful to > allow any ND or other options developed for phase 1 to be re-used for a > phase 2 solution if they can. > > Any thoughts on this approach ? If some options can be found for ND which significantly improve the situation in (1), then by all means :) I personally think that we should resign ourselves to the fact that a single L2 segment having the same MTU is less likely to occur in future, rather than more likely so any attempts to try and find a unified MTU for a link is unlikely to be profitable. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 05:17:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLZQ-0006RJ-Uw; Tue, 26 Jul 2005 05:17:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLZP-0006RE-V4 for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 05:17:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00747 for ; Tue, 26 Jul 2005 05:17:49 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxM4R-0004JI-DE for ipv6@ietf.org; Tue, 26 Jul 2005 05:49:56 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6Q9HUIh009393; Tue, 26 Jul 2005 11:17:30 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6Q9HUjU029336; Tue, 26 Jul 2005 11:17:30 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6Q9HUgI029335; Tue, 26 Jul 2005 11:17:30 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 26 Jul 2005 11:17:30 +0200 From: Stig Venaas To: Perry Lorier Message-ID: <20050726091730.GB29226@storhaugen.uninett.no> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> <20050726121143.53648467.ipng@69706e6720323030352d30312d31340a.nosense.org> <42E5F743.2000506@coders.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <42E5F743.2000506@coders.net> User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tyholt.uninett.no id j6Q9HUIh009393 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, Jul 26, 2005 at 08:41:39PM +1200, Perry Lorier wrote: >=20 > > I'd like to suggest a two phased development approach, based on wheth= er > > layer 2 can be assumed to fully support the larger MTUs or not (I thi= nk > > the following is also probably a summary of the couple of threads of > > discussion in the emails of the last couple of days) : > >=20 > > (1) Making the assumption that layer 2 can support larger, non-standa= rd > > MTUs (as it has been engineered to by a network designer), develop > > mechanisms that allow nodes to announce their non-standard, larger MT= U > > support. If a pair of nodes find they both support larger MTUs/MRUs, > > then they'll take advantage of it for unicast traffic. If the unicast > > communcations fails because layer 2 doesn't support the MTU/MRUs it i= s > > supposed to, then layer 2 is broken and it is up to network admin to > > fix it. >=20 > It's difficult to say what MTU L2 should support. If you have a GigE > link then you might assume 9k MTU's (which varient of 9k?), and the > remote end also might have GigE, but there is a 100mbit switch in the > middle preventing communication between both ends to use 9k MTU's. >=20 > You can barely assume 1500 as people tend to tunnel things, you can get > technologies like vlans, 802.1x or mpls eating heavily into your mtu. > You should assume 1280 bytes and hope that you can raise it. You can't really assume 1500 on L3, but PMTU discovery should work there. On L2 I thought you generally had 1500 despite vlans and 1x. > More and more end users aren't qualified network admins, they are peopl= e > who plug device A into device B and expect everything to "just work". > Given how many PMTU failures you see on the production internet today, > assuming even qualified network admins have the time and resources to > debug current MTU mismatches seems unlikely let alone future ones. >=20 > Any system which requires admin intervention to work IMHO will be a > dismal failure. >=20 > > In all other cases (eg. multicast, unicast without these announcement= s), > > the MTU used will be the either the link layer MTU standard or the li= nk > > MTU value as announced in RAs (i.e., along the lines that this MTU va= lue > > has been announced because the link layer technology doesn't have a > > standard value e.g. token ring. There is a corner case that needs to = be > > covered where a larger than standard MTU has been annnounced for a > > technology that does have a fixed MTU e.g. 1500 byte ethernet, and a > > sub-set of nodes only support the standard size). >=20 > For multicast it seems wise to just "give up" and use 1280. Even if yo= u > can determine the MTU of all nodes in a multicast group, there are no > assurances that it is going to remain stable and changes are much harde= r > to deal with than the unicast case. Maybe allow an admin to tune this > higher if they want to. PMTU discovery does work for IPv6 multicast (you're supposed to get packet too big ICMP messages) and at least implementations I'm familiar with do indeed support it. It is less stable since the PMTU might change when people join or leave the group. With respect to L2 it's not an issue as long as the hosts interface is configured to a common L2 MTU. Supporting different MTUs for different hosts on the same link sounds rather scary IMO. > > These mechasims only come into play if non-standard MTU support has b= een > > enabled (in some mechanism specific manner, which may be via a new RA > > option, or even just configuring larger, non-standard MTUs on the > > interfaces that are capable of larger frames). The out-of-the-box > > plug-and-play IPv6 functionality that exists today will be preserved = if > > these mechanisms aren't enabled, by all nodes using the link standard= MTU > > or RA announced MTU.=20 >=20 >=20 > > I think this solution would be relatively quick and simple to develop= , > > and is applicable to any networks that have been specifically designe= d > > to support larger, non-standard MTUs.=20 > >=20 > > (2) Develop mechansisms that can dynamically discover MTU/MRU sizes, > > limitations and variations over time, including within intermediary > > layer 2 devices e.g., switches. It seems that some solutions have > > already started to be developed in this area, including the email > > discussion between Iljitsch and Perry, Matt Mathis in > > draft-ietf-pmtud-method-04.txt and Fred Templin in > > draft-templin-ipvlx-02.txt. > >=20 > > If the above phased approach is followed, I think it would be useful = to > > allow any ND or other options developed for phase 1 to be re-used fo= r a > > phase 2 solution if they can. > >=20 > > Any thoughts on this approach ? >=20 > If some options can be found for ND which significantly improve the > situation in (1), then by all means :) I personally think that we > should resign ourselves to the fact that a single L2 segment having the > same MTU is less likely to occur in future, rather than more likely so > any attempts to try and find a unified MTU for a link is unlikely to be > profitable. My personal perhaps na=EFve thinking is that the administrator should configure all hosts on the link to a common MTU, and ND RAs would have been a fine tool for that. But according to 2464 it seems it must be configured in some other way. Stig > -------------------------------------------------------------------- > 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 Jul 26 07:05:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxNFw-0003Qt-2Q; Tue, 26 Jul 2005 07:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxNFu-0003Pl-Un for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 07:05:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06555 for ; Tue, 26 Jul 2005 07:05:48 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxNkw-0007Rt-I2 for ipv6@ietf.org; Tue, 26 Jul 2005 07:37:56 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6QB6Ik0099034 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 26 Jul 2005 13:06:18 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20050726121143.53648467.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> <20050726121143.53648467.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A8C4AFD-E882-4644-84F2-2B5E4089FD06@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Tue, 26 Jul 2005 13:05:31 +0200 To: Mark Smith X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 26-jul-2005, at 4:41, Mark Smith wrote: > I'd like to suggest a two phased development approach, based on > whether > layer 2 can be assumed to fully support the larger MTUs or not (I > think > the following is also probably a summary of the couple of threads of > discussion in the emails of the last couple of days) : > (1) Making the assumption that layer 2 can support larger, non- > standard > MTUs (as it has been engineered to by a network designer), develop > mechanisms that allow nodes to announce their non-standard, larger MTU > support. If a pair of nodes find they both support larger MTUs/MRUs, > then they'll take advantage of it for unicast traffic. If the unicast > communcations fails because layer 2 doesn't support the MTU/MRUs it is > supposed to, then layer 2 is broken and it is up to network admin to > fix it. You mean: if I hook up two hosts that support 9k jumboframes to a cheap unmanaged 10/100 switch (all out of the box) and it doesn't work, I have to go in and reconfigure the hosts so it does work? Sorry, but that's not acceptable. And the case where I have to enable jumboframes on the hosts and then everything fails because the switch can't handle it is barely usable. It allows for jumbo and non-jumbo capable hosts to live on the same subnet, which is an important advantage, but it's still extremely fragile for no good reason. What we need in addition to this would be (as outlined in my message to Bob): - a mechanism to distribute the MTU for the layer 2 network to jumbo- capable systems - validation that jumboframes indeed work to minimize the impact of misconfiguration > In all other cases (eg. multicast, unicast without these > announcements), > the MTU used will be the either the link layer MTU standard or the > link > MTU value as announced in RAs Right. > There is a corner case that needs to be > covered where a larger than standard MTU has been annnounced for a > technology that does have a fixed MTU e.g. 1500 byte ethernet, and a > sub-set of nodes only support the standard size). If the nodes announce their MTU/MRU in neighbor advertisements this isn't a problem: jumbo-capable hosts wouldn't send jumboframes to neighbors that don't support them. > These mechasims only come into play if non-standard MTU support has > been > enabled Yes, this is important. > (in some mechanism specific manner, which may be via a new RA > option, Suboptimal because switches can't easily do this. > or even just configuring larger, non-standard MTUs on the > interfaces that are capable of larger frames). Very suboptimal because it requires manual configuration of all nodes. > The out-of-the-box > plug-and-play IPv6 functionality that exists today will be > preserved if > these mechanisms aren't enabled, Yes, and the destructive potential of nuclear bombs is mitigated if you don't detonate them... This is 2005 and IPv6. Autoconf is the word, is the word that you heard. It's got groove, it's got meaning. Autoconf is the time, is the place is the motion. Autoconf is the way we are feeling. > (2) Develop mechansisms that can dynamically discover MTU/MRU sizes, > limitations and variations over time, including within intermediary > layer 2 devices e.g., switches. It seems that some solutions have > already started to be developed in this area, including the email > discussion between Iljitsch and Perry, :-) We can certainly experiment with this while we roll out the more conservative approach. > Matt Mathis in > draft-ietf-pmtud-method-04.txt and Fred Templin in > draft-templin-ipvlx-02.txt. I don't really see how those apply. > If the above phased approach is followed, I think it would be > useful to > allow any ND or other options developed for phase 1 to be re-used > for a > phase 2 solution if they can. Of course. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 07:47:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxNtt-00042o-AM; Tue, 26 Jul 2005 07:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxNtr-00042j-Bm for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 07:47:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09097 for ; Tue, 26 Jul 2005 07:47:06 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx1.orcon.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxOOr-0000OK-ET for ipv6@ietf.org; Tue, 26 Jul 2005 08:19:12 -0400 Received-SPF: none (dbmail-mx1.orcon.net.nz: domain of perry@coders.net does not designate permitted sender hosts) receiver=dbmail-mx1.orcon.net.nz; client-ip=60.234.141.149; envelope-from=; helo=elmer.coders.tla; Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx1.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j6QBlmug001529 for ; Tue, 26 Jul 2005 23:47:51 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1DxNtY-0006Eh-00 for ; Tue, 26 Jul 2005 23:46:48 +1200 Message-ID: <42E622A7.8040206@coders.net> Date: Tue, 26 Jul 2005 23:46:47 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050724 X-Accept-Language: en-nz, en MIME-Version: 1.0 CC: IETF IPv6 Mailing List References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> <42E25E62.2010805@coders.net> <17E800F8-AAFF-4B67-8CF9-42CB69038694@muada.com> <42E394B2.5020409@coders.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: ClamAV 0.86.1/993/Tue Jul 26 19:28:36 2005 on dbmail-mx1.orcon.net.nz X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dbmail-mx1.orcon.net.nz id j6QBlmug001529 X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Content-Transfer-Encoding: quoted-printable Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>> 1. do not impede 1500-byte operation >>> 2. discover and utilize jumboframe capability where possible >>> 3. discover and utilize (close to) the maximum MTU >>> 4. recover from sudden MTU reductions fast enough for TCP and similar >>> to survive >> 5. Must be fully automatic and not require any admin intervention to = do >> the "right" thing. >> 6. Minimise the resources used. >=20 > Agree, except that packets are cheap on a 1000 Mbps LAN, so those don'= t > count much towards 6. Packet rate however starts becoming a problem at faster speeds, at gige it starts becoming a problem for hosts to deal with unless they are careful. And not all networks are fast, 3G networks are becoming more prevalent. We should not waste resources needlessly :) >>> However, this doesn't accommodate finding out jumboframe support at >>> reduced sizes very well. For this, I think we should use an additio= nal >>> exchange, but this one should probably happen over multicast. >=20 >=20 >> I disagree. There is no need to for every host to have a full >> understanding of the layer 2 topology of the network it is on. >=20 >=20 > That's not what the mechanism that I outlined does. What it does do is > let all jumbo-capable system send send at least one packet at their > maximum size and get feedback on whether it was received by anyone. Fo= r > that, every packet may update information that the system (host or > router) holds, but then the old information is gone so there is no > per-(potential) correspondent state. Ok, I sat down and reread it a few more times and I think I've got more what you're trying to get at now. >> We're >> starting to see some very large L2 networks as MAN's (eg NLR[1]) and >> IPv6's /64 per subnet puts no real practical limit on how large a sin= gle >> L2 segment can be. >=20 >=20 > Hm, they invented routers for a reason. You know, that was exactly my thought when I heard about it too. :) > I don't think we have to bend over backwards to accommodate unreasonabl= y > large layer 2 networks. But: what would be reasonable to accommodate? > 1000 systems? I think it's probable that 1000 systems would be quite feasible. It's also possible that as the scarcity of addresses is relieved that people move back towards IP based virtual hosting. How many SSL sites would a single ISP want to host if it could do so easily? If you have a big outdoor concert with some AP's covering it you could have thousands of people all ending up sharing a L2. > I'm not sure this is a problem: as far as I know (and that's not too=20 > far) switches use per-port buffer space, so although such a packet use= s > up buffer space for a lot of ports, there is nothing unreasonable abou= t > that (packet is gone again in 72 microseconds anyway). But some vendor > feedback would be good here. Fair enough. >> What happens on l2's where not every node can see every other node? >=20 > Neighbor discovery fails? Host A can talk to Host B ok. Host A can talk to Host C ok. Host B can't talk to Host C. This happens in ad hoc wireless networks. With your system I'm not entirely sure how you deal with who's "turn" it is next if not all nodes can see all other nodes. Host A should still be able to talk to Host B. >> Some L2's only allow end hosts to talk to a master host. What about a >> network with vlans where some hosts are on differing sets of vlans? >=20 > I don't think those exist in that way. Ad hoc wireless was a much better example ;) >>> A C >>> | | >>> +-+--+ +----+ +--+-+ >>> |9000+--+3000+--+8000| >>> +-+--+ +----+ +--+-+ >>> | | >>> B D >=20 >=20 >> If A and B are talking to each other and C and D are talking to each >> other, why do (A and B) need to talk to C and D? >=20 > Ah, but how do you know that A doesn't talk to D, and is never going to= ? How do you know it will in the time before the topology of the network changes? Given that the topology of the network changes every time a host comes and goes, the chance that you'll want to talk to most of the users during time is rather low. >> Why not a simpler protocol? >=20 >=20 >> Host A sends a ND to Host B with Host A's MRU. >> Host B replies with a NS to Host A with Host B's MRU. >> Host A can now start transmitting the data it wants to send. >> Host A now sends Host B a ICMP MTU Probe, at some size less than or >> equal to Host B's MRU >> If Host B receives the packet, it replies with an ICMP MTU Probe reply >> saying what it received. >=20 >=20 > The problem here is that if the switches in the middle don't support=20 > jumboframe sizes A and B do, you can't use jumboframes at all. Since=20 > there is no standard jumboframe size, this is a problem. Of course A=20 > and B can discover the maximum size between them, but doing that=20 > between any set of correspondents seems suboptimal. > On the other hand, if we reuse the information learned for previous=20 > correspondents, this could work well. >=20 > So: >=20 > When ND indicates a neighbor supports jumboframes we start by sending > an MTU prope with either an MTU that worked towards another=20 > correspondent fairly recently (last hour or so). If the correspondent=20 > receives this packet it sends an ack and both sides can increase the M= TU. I'd start at the minimum "MTU" size. A colleague of mine (Matthew Luckie) has done some research into path MTU's. He has a work in progress paper ( http://www.wand.net.nz/~mjl12/debugging-pmtud.pdf ) where he enumerates all the common MTU's he's seen on the Internet. I'd start with a similar table trying the lowest size, and sending that, if it's received try the next lowest size and so on until you don't get a reply. When you don't get a reply try the previous-mtu-that-worked+1, if that succeeds start a binary search between previous-mtu-that-worked and the one that didn't. For a "common" MTU, you only have to endure two timeouts (the next highest common MTU, and the +1 test). For an uncommon MTU you can increase the MTU to maximum "common" MTU that's lower than your MTU quickly, and can endure the timeouts from then on. If you pick a common MTU and hope, you end up having to endure timeouts in the case of an incorrect guess. If you don't want to hard code that table into your stack, you can at least do something simple like increment the probed MTU by say 512. > However, it's possible we can improve on this MTU, so now we do a=20 > binary search between the current MTU and the maximum usable one (=3D=20 > minimum of local and remote MTU/MRUs), at one packet per second or so. You want to try and avoid doing a binary search because about 50% of the time, you're going to have a timeout. log2(9000-1500)>10, thats 10 timeouts, if each timeout is a second or so as you suggest, then that's over 10 seconds for a successful mtu probe. If you start low and move higher then you'll get a successful response from the remote end immediately, increasing your MTU every round trip. As soon as you get a timeout, you hope that the MTU you tried was the previously successful "common MTU", so you try that one +1, to make sure it fails. If it succeeds then it's a completely "unknown" MTU so only then do you fall back to a binary search. [later after reading below], hrm you're suggesting sending two packets at once, which is fine this so long as reordering doesn't occur (which seems unlikely at L2). > If the first probe with a recently used MTU fails then we do a binary=20 > search betwen that value and an initial one, which should probably be=20 > 1508 (some NICs don't do jumboframes but support 1504 for VLAN use,=20 > nearly all MTUs are 32 bit aligned, the maximum 3 extra bytes aren't=20 > worth it anyway). Yep. See the table I quoted above. > I think we can assume the MTU is the same in both directions.=20 I agree. > So when system A tries with 3000 bytes (worked with C!) towards B, B se= ts an=20 > ack flag and tries with 9216, which fails, so A sends a NAK and tries=20 > with 6108, and so on.=20 Hang on, if they don't receive a packet, how can they know to send a NAK? if they're just waiting for a timeout how can they know if the packet got lost on the way there or on the way back? > With each successful packet (either received or > acknowledged) the MTU towards the correspondent can be increased=20 > immediately. Yep! So you want to increase your chances of successful packets getting through :) >> By working "up" known sizes instead of doing a binary search (or work= ing >> down), Host A can quickly ratchet up sizes without waiting for a time= out >> gaining immediate benefits from larger MTUs as they are discovered. >=20 >=20 > You can do this with binary search too, as long as you send a separate > "now testing YYYY, ack XXXX" packet. Doubling the number of packets that need to be sent. Chances are it's going to be one of a very few sizes, and as you say, it'll probably even be the size that the other ones on the link are. If instead of using special "ICMP MTU Probes" we use "ICMP Echo request" /"ICMP Echo Reply" messages, there is no changes to any packet formats needed, all it needs to be done is have implemented in a TCP/IP stack, and the concept is even reusable for IPv4. Other hosts don't even have to be upgraded to support this either. magic! Stacks would be free to do as you suggest (doing a binary search) or as I suggest (ramp up and do a binary search only as a last resort). So the general approach would be: * If a packet arrives from a host that is larger than the cached MTU for that neighbour, increase it to the size of the packet arriving. * When receiving a ND (but not a NS!), and you have no cached MTU for that neighbour, you start the MTU discovery process (using any mechanism for selecting the packet sizes the implementation deems appropriate (ie, either yours, or mine, or if someone can come up with a method thats even better than ours, they could use that!) > I don't think we want to do this at top speed, though, because the=20 > control traffic could get in the way of real traffic. Hrm, now thats a good point. Ah, but you should only be putting one packet onto the network after another packet has come off, so you can't overflow any queues with it. >> Assuming no reordering you then don't have to wait for a timeout. If >> reordering does occur you then send a "Whoops! reordering! didn't exp= ect >> that on the same L2!" and then everyone flags that interface as >> "possible reordering" and then always waits for a timeout. >=20 >=20 >> In the common case of no reordering this will be much faster due to n= ot >> waiting for timeouts. >=20 >=20 > If the "I sent..." packet comes in before the actual test packet, then > this would look like the test packet didn't make it, so the receiver > would send a NAK. However, if the packet does make it and comes in > late, then obviously the receiver notices this and it can send out an > ACK as well. Since we don't want to hammer the layer 2 network with > possibly invalid packets, the receiver (well, sender of the original > probe) would probably want to wait long enough for that ACK to come in > before sending the next packet anyway. Hammering shouldn't be too bad -- You're only putting a packet onto the network when a packet is taken off it, so you can't overflow any buffers. With packet rate issues, any host which is "slow" just slows down the rate of packets being sent to the rate that it can cope. >> Not everything has a MAC address. >=20 > Yikes! You really are a modern day Ren=E9 Descartes, aren't you? :-) Well, this needs to work on L2's that aren't Ethernet (even if there aren't many of them left!) so assumptions that everything has a MAC may be premature. >> Difference in link local addresses? >> This sounds very much like turning Ethernet into token ring . >=20 > Ring networks are very cool, too bad we don't have them anymore. Heh, indeed. :) >>> Alternatively, we could add an RA option that administrators can=20 >>> use to >>> tell hosts the jumboframe size the layer 2 network supports. (The RA >>> option doesn't say anything about the capabilities of the _router_.) >>> Then the whole multicast taking turns discovery isn't necessary,=20 >>> and we >>> can suffice with a quick one-to-one verification before jumboframes >>> are >>> used. >=20 >> This still seems to fall foul of either requiring the administrator to >> configure the router >=20 > Well, that's what administrators do, isn't it? Not when it's my flatmate who wants to plug his shiny new console into the switch and have it "just work". Even if I understand MTU's I really don't want to start trying to figure out what MTU's all the switches on a large campus are. What was the MTU of the 3 port switch in my VoIP phone? Who knows? And to be perfectly honest, who the hell cares? :) I should plug everything in and it should "just go" and have the best possible performance. >> or degrading the entire network to the level of the >> router. >=20 > No, the announcement "the switch can handle 4500 bytes" wouldn't have=20 > anything to do with "I can handle 1500". Which switch? I live in a flat with 3 other people, we have at least 4 devices that act like switches on one segment. (2 switches, a voip phone (you can daisy chain a PC off it), and an AP). I have no idea what the maximum MTU of all those switches are, let alone all the end hosts around here. Sure I could spend an afternoon configuring everything just right so that I get the maximum possible efficiency through my network, but it's unreasonable to think that everyone else in the world will. > It's probably a good idea to make announcements like this part of the=20 > protocol, but not as RA options. That way, switches can announce their > own MTU capabilities, even if they don't otherwise support IPv6. So if > the switch says that it can do 4500, we only have to try 4500 (ack) an= d > 4504 (nak) and everything is much faster. (Unless the layer 2 network > is more complex, of course, but then either 4500 gets a nack/timeout o= r > 4504 gets an ack.) >=20 > Hm, maybe 4 bytes larger than an earlier maximum is always a good idea= ... >=20 > It would be even better if we could ask the switch what our port=20 > supports, but I'm not sure how to do this in such a way that a switch=20 > that doesn't support this protocol floods the request so the results=20 > are meaningless. Hrm, so Ethernet has capability negotiation (which is how speed, duplex, pause frame support etc is negotiated). I have no idea if it says if the switch supports jumbo gram, IEEE specs make my head hurt. [hrm, this email is getting rather long :) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 09:06:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxP8p-00077C-0q; Tue, 26 Jul 2005 09:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxP8m-00074n-AS for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 09:06:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15861 for ; Tue, 26 Jul 2005 09:06:34 -0400 (EDT) Received: from smta00.mail.ozemail.net ([203.103.165.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxPdo-0003HL-Ax for ipv6@ietf.org; Tue, 26 Jul 2005 09:38:42 -0400 Received: from ubu.nosense.org ([210.84.225.248]) by smta00.mail.ozemail.net with ESMTP id <20050726130621.UIHL10382.smta00.mail.ozemail.net@ubu.nosense.org>; Tue, 26 Jul 2005 13:06:21 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 8B3AE62AAE; Tue, 26 Jul 2005 22:36:20 +0930 (CST) Date: Tue, 26 Jul 2005 22:36:20 +0930 From: Mark Smith To: Iljitsch van Beijnum Message-Id: <20050726223620.6154d8f4.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <2A8C4AFD-E882-4644-84F2-2B5E4089FD06@muada.com> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> <20050726121143.53648467.ipng@69706e6720323030352d30312d31340a.nosense.org> <2A8C4AFD-E882-4644-84F2-2B5E4089FD06@muada.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; 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.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Iljitsch, On Tue, 26 Jul 2005 13:05:31 +0200 Iljitsch van Beijnum wrote: > On 26-jul-2005, at 4:41, Mark Smith wrote: > > > I'd like to suggest a two phased development approach, based on > > whether > > layer 2 can be assumed to fully support the larger MTUs or not (I > > think > > the following is also probably a summary of the couple of threads of > > discussion in the emails of the last couple of days) : > > > (1) Making the assumption that layer 2 can support larger, non- > > standard > > MTUs (as it has been engineered to by a network designer), develop > > mechanisms that allow nodes to announce their non-standard, larger MTU > > support. If a pair of nodes find they both support larger MTUs/MRUs, > > then they'll take advantage of it for unicast traffic. If the unicast > > communcations fails because layer 2 doesn't support the MTU/MRUs it is > > supposed to, then layer 2 is broken and it is up to network admin to > > fix it. > > You mean: if I hook up two hosts that support 9k jumboframes to a > cheap unmanaged 10/100 switch (all out of the box) and it doesn't > work, I have to go in and reconfigure the hosts so it does work? > > Sorry, but that's not acceptable. > I think that is an uncommon scenario. How many hosts with jumbo frame capable interfaces come with jumbo frame capablility _enabled by default_ ? The complex "cope with any MTU on any device" solution is really trying to address what I think would currently be the worst case scenario. I don't think that scenario will be all that common, at least in the short to medium term because : (a) devices that are jumbo frame capable don't come with them enabled by default (b) people who enable jumbo frames usually know what they're doing and what is required for them to work ie. a layer 2 infrastructure that will support them. If you enable jumbo frames on end-nodes without a layer 2 infrastructure that supports them, then you get what you deserve - a network that won't work. The solution of course is go back to standard size frames or buy jumbo capable layer 2 infrastructure and enable it. I think it's really as simple as that. Don't fall into the trap of assuming the worst case scenario will be the common one. I think the common one is that people who specifically buy _and want to enable_ jumbo frame capable end-nodes will also make sure they buy jumbo frame capable layer 2 infrastructure. > And the case where I have to enable jumboframes on the hosts and then > everything fails because the switch can't handle it is barely usable. > It allows for jumbo and non-jumbo capable hosts to live on the same > subnet, which is an important advantage, but it's still extremely > fragile for no good reason. > See above. You broke the network by enabling a feature on your end-nodes that your network doesn't support. > What we need in addition to this would be (as outlined in my message > to Bob): > > - a mechanism to distribute the MTU for the layer 2 network to jumbo- > capable systems There are probably a few RA announced-style MTU values that need to be distributed around : (a) the original MTU that is currently in RAs - the "whole of link" one. This is the MTU that all nodes on the link must be capable of receiving, as it will be used as the maximum size for multicasts. Not really necessary for ethernets as this value would normally be 1500 bytes, although there are some uses for ethernets if all offlink destinations are via a link with a slightly smaller MTU e.g., and IPsec tunnel, to avoid a PMTUD cycle. The other reason to specifically set it is to cope with layer 2 technologies such as token ring which don't have a standardised MTU. (b) the "link maximum jumbo" ie. the absolute largest MTU that the layer 2 infrastructure can support. Nodes that can support jumbo frames can raise their MTU up to either the maximum MTU they support above the standard value that is less than this value (eg 7k if they don't support 9K jumbos (they exist, even in fast ethernet. My Netgear Fa312s under Linux support MTUs of 2024 bytes !)) or set their MTU to this value, which may actually be smaller than the jumbo size they're capable of supporting (I think I've read that some Intel GigE NICs can support 16K jumbos). This value would be configured on the routers making RA announcements after the layer 2 infrastructure has been had jumbo frame capability enabled. > - validation that jumboframes indeed work to minimize the impact of > misconfiguration > Once your layer 2 infrastructure is known to support a specific jumbo frame size, I don't think it is all that necessary to check for it anymore. The overheads of checking for it all the time may be too high when compared to how often unauthorised standard MTU or unconfigured switches are plugged in to the network. > > In all other cases (eg. multicast, unicast without these > > announcements), > > the MTU used will be the either the link layer MTU standard or the > > link > > MTU value as announced in RAs > > Right. > > > There is a corner case that needs to be > > covered where a larger than standard MTU has been annnounced for a > > technology that does have a fixed MTU e.g. 1500 byte ethernet, and a > > sub-set of nodes only support the standard size). I think my "link jumbo maximum" description previously provides a solution to this corner case. > > If the nodes announce their MTU/MRU in neighbor advertisements this > isn't a problem: jumbo-capable hosts wouldn't send jumboframes to > neighbors that don't support them. > Agree. > > These mechasims only come into play if non-standard MTU support has > > been > > enabled > > Yes, this is important. > > > (in some mechanism specific manner, which may be via a new RA > > option, > > Suboptimal because switches can't easily do this. > Which is why I'd have the routers do it in their RAs. > > or even just configuring larger, non-standard MTUs on the > > interfaces that are capable of larger frames). > > Very suboptimal because it requires manual configuration of all nodes. > > > The out-of-the-box > > plug-and-play IPv6 functionality that exists today will be > > preserved if > > these mechanisms aren't enabled, > > Yes, and the destructive potential of nuclear bombs is mitigated if > you don't detonate them... This is 2005 and IPv6. Autoconf is the > word, is the word that you heard. It's got groove, it's got meaning. > Autoconf is the time, is the place is the motion. Autoconf is the way > we are feeling. > The problem is going too far with the goal of PnP, and then ending up with monsterously complex solutions that attempt to address every possible scenario, including the most esoteric onces, rather than just the common ones (ie. common operational scenarios, common failure scenarios). > > (2) Develop mechansisms that can dynamically discover MTU/MRU sizes, > > limitations and variations over time, including within intermediary > > layer 2 devices e.g., switches. It seems that some solutions have > > already started to be developed in this area, including the email > > discussion between Iljitsch and Perry, > > :-) > Don't get me wrong, I'd like this solution to be developed. I'm just wondering how hard it might be to develop, and if there is simpler interrim "sub-solution" that would still be useful to a fair number of people, namely those who don't expect to just "plug-and-play" when they want to use non-standard protocol parameters and feature, such as jumbo frames. Once a fully fledged "cope with any MTU" solution exists, then manufacturers of NICs and switches could enable jumbo frames by default. > We can certainly experiment with this while we roll out the more > conservative approach. > > > Matt Mathis in > > draft-ietf-pmtud-method-04.txt and Fred Templin in > > draft-templin-ipvlx-02.txt. > > I don't really see how those apply. > Only because from what I remember of Matt's draft, and what Fred said about his, they perform some sort of MTU discovery without relying on a feedback mechanism e.g. ICMP Dest Unreachable, Packet Too Big, which I think you solution would have to deal with, assuming that there wasn't a requirement to add protocols to the switches. > > If the above phased approach is followed, I think it would be > > useful to > > allow any ND or other options developed for phase 1 to be re-used > > for a > > phase 2 solution if they can. > > Of course. 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 Jul 26 09:23:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPOj-0004jr-KK; Tue, 26 Jul 2005 09:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPOh-0004jm-S9 for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 09:23:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17318 for ; Tue, 26 Jul 2005 09:23:02 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx3.orcon.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxPtk-0003yA-GF for ipv6@ietf.org; Tue, 26 Jul 2005 09:55:10 -0400 Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx3.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j6QDPA3h011520 for ; Wed, 27 Jul 2005 01:25:10 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1DxPOc-0006VO-00 for ; Wed, 27 Jul 2005 01:22:58 +1200 Message-ID: <42E63932.3000403@coders.net> Date: Wed, 27 Jul 2005 01:22:58 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050724 X-Accept-Language: en-nz, en MIME-Version: 1.0 CC: ipv6@ietf.org References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> <20050726121143.53648467.ipng@69706e6720323030352d30312d31340a.nosense.org> <2A8C4AFD-E882-4644-84F2-2B5E4089FD06@muada.com> <20050726223620.6154d8f4.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050726223620.6154d8f4.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/993/Tue Jul 26 19:28:36 2005 on dbmail-mx3.orcon.net.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > > If you enable jumbo frames on end-nodes without a layer 2 infrastructure > that supports them, then you get what you deserve - a network that won't > work. The solution of course is go back to standard size frames or buy > jumbo capable layer 2 infrastructure and enable it. I think it's really > as simple as that. > > Don't fall into the trap of assuming the worst case scenario will be the > common one. I think the common one is that people who specifically buy > _and want to enable_ jumbo frame capable end-nodes will also make sure > they buy jumbo frame capable layer 2 infrastructure. > If you're going to require admins enabling jumbograms on their network, it's never going to happen. People are just going to avoid enabling it because when you do everything breaks. As it stands today the general consensus is "disable jumbograms, coz even if you manage to get it all working today, something will change tomorrow and you'll have a nasty problem to fix". If a simple solution can be found to having one link support multiple MTU's then thats where I think we should be heading :) If one can't be found, then we should investigate what we can do to make this as easy as possible for end users. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 09:50:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPos-0002LY-Sx; Tue, 26 Jul 2005 09:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPoo-0002KP-Rc for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 09:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18856 for ; Tue, 26 Jul 2005 09:50:01 -0400 (EDT) Received: from relay-pt1.siemens.pt ([194.145.62.202] helo=relay2.siemens.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxQJs-0004kr-1H for ipv6@ietf.org; Tue, 26 Jul 2005 10:22:09 -0400 Received: from fw-mta2.siemens.pt (fw-mta2.siemens.pt [141.29.156.202]) by relay2.siemens.pt (8.12.8/8.12.9) with ESMTP id j6QDS80a012635; Tue, 26 Jul 2005 14:28:10 +0100 Received: from lisi053a.siemens.pt (lisi053a.siemens.pt [141.29.156.193]) by fw-mta2.siemens.pt (Hvm) with ESMTP id j6QDoqm11989; Tue, 26 Jul 2005 14:50:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Jul 2005 14:49:09 +0100 Message-ID: <0248B0F35AF7B8418CA72E88AC00BF1F2FEEBF@lisi053a.siemens.pt> Thread-Topic: jumbo frame of GbE and IPv6 Thread-Index: AcWR5bcTH+D7fBwyQwScJhLC5aZsSAAAky1Q From: "Nuno Garcia" To: "Perry Lorier" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ipv6@ietf.org Subject: RE: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org 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="===============0929748324==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0929748324== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgYWxsOg0KIA0KU29ycnkgdG8gZHJvcCBpbiB3aGl0b3V0IGFueXRoaW5nIHRoYXQgaW1wb3J0 YW50IHRvIHNheToNCiANCmp1bWJvZ3JhbXMgYXJlIG5vdCB0aGUgc2FtZSBhcyBqdW1ib2ZyYW1l cyAtIHRoZSBmaXJzdCBpcyBJUHY2IChhbmQgY2FycmllcyBhIG1heCBvZiA0R0IgZGF0YSksIHRo ZSBsYXRlciBpcyBFdGhlcm5ldCAoYW5kIGl0IGNhcnJpZXMgdXAgdG8gOUtCIGRhdGEpLg0KIA0K U28gaWYgd2Ugd2FudCB0byBrZWVwIHRoZSBkaXNjdXNzaW9uIGZpbmUgdHVuZWQsIHdlIG1pZ2h0 IHdhbnQgbm90IHRvIG1peCB1cCB0aGVzZSB0d28gY29uY2VwdHMuDQogDQpCVFcsIEknbSBhbGwg aW4gZmF2b3VyIGluIHJldGhpbmtpbmcgdGhlICJqdW1ibyIgaXNzdWUgKG9yIGFzIHNvbWVvbmUg b25jZSBwdXQgaXQsIHRvIGdpdmUgYW4gZW5kIHRvIHRpbnlncmFtcyksIGFuZCBvZiBjb3Vyc2Us IHRvIG1ha2VpdCBhcyBtdWNoIEF1dG9jb25mIGFzIHBvc3NpYmxlLg0KIA0KSWYgd2UgbWFrZSBz b21lIHNpbXBsZSBhcml0aG1ldGljcywgd2UgY2FuIHNlZSB0aGUgc2l6ZSBvZiB0aGUgc3dpdGNo aW5nIGVmZm9ydCB3ZSdyZSBwb3Npbmcgb24gbmV0d29ya3MgZXF1aXBtZW50cyB3aXRoIHRoaXMg MTUwMEIgdGlueWdyYW1zLg0KIA0KQ2hlZXJzLA0KIA0KTnVubyBNLiBHYXJjaWEsDQpTaWVtZW5z IFNBDQpQb3J0dWdhbA0KDQoJLS0tLS1NZW5zYWdlbSBvcmlnaW5hbC0tLS0tIA0KCURlOiBpcHY2 LWJvdW5jZXNAaWV0Zi5vcmcgZW0gbm9tZSBkZSBQZXJyeSBMb3JpZXIgDQoJRW52aWFkYTogdGVy IDI2LTA3LTIwMDUgMTQ6MjIgDQoJUGFyYTogDQoJQ2M6IGlwdjZAaWV0Zi5vcmcgDQoJQXNzdW50 bzogUmU6IGp1bWJvIGZyYW1lIG9mIEdiRSBhbmQgSVB2Ng0KCQ0KCQ0KDQoNCgk+DQoJPiBJZiB5 b3UgZW5hYmxlIGp1bWJvIGZyYW1lcyBvbiBlbmQtbm9kZXMgd2l0aG91dCBhIGxheWVyIDIgaW5m cmFzdHJ1Y3R1cmUNCgk+IHRoYXQgc3VwcG9ydHMgdGhlbSwgdGhlbiB5b3UgZ2V0IHdoYXQgeW91 IGRlc2VydmUgLSBhIG5ldHdvcmsgdGhhdCB3b24ndA0KCT4gd29yay4gVGhlIHNvbHV0aW9uIG9m IGNvdXJzZSBpcyBnbyBiYWNrIHRvIHN0YW5kYXJkIHNpemUgZnJhbWVzIG9yIGJ1eQ0KCT4ganVt Ym8gY2FwYWJsZSBsYXllciAyIGluZnJhc3RydWN0dXJlIGFuZCBlbmFibGUgaXQuIEkgdGhpbmsg aXQncyByZWFsbHkNCgk+IGFzIHNpbXBsZSBhcyB0aGF0Lg0KCT4NCgk+IERvbid0IGZhbGwgaW50 byB0aGUgdHJhcCBvZiBhc3N1bWluZyB0aGUgd29yc3QgY2FzZSBzY2VuYXJpbyB3aWxsIGJlIHRo ZQ0KCT4gY29tbW9uIG9uZS4gSSB0aGluayB0aGUgY29tbW9uIG9uZSBpcyB0aGF0IHBlb3BsZSB3 aG8gc3BlY2lmaWNhbGx5IGJ1eQ0KCT4gX2FuZCB3YW50IHRvIGVuYWJsZV8ganVtYm8gZnJhbWUg Y2FwYWJsZSBlbmQtbm9kZXMgd2lsbCBhbHNvIG1ha2Ugc3VyZQ0KCT4gdGhleSBidXkganVtYm8g ZnJhbWUgY2FwYWJsZSBsYXllciAyIGluZnJhc3RydWN0dXJlLg0KCT4NCgkNCglJZiB5b3UncmUg Z29pbmcgdG8gcmVxdWlyZSBhZG1pbnMgZW5hYmxpbmcganVtYm9ncmFtcyBvbiB0aGVpciBuZXR3 b3JrLA0KCWl0J3MgbmV2ZXIgZ29pbmcgdG8gaGFwcGVuLiAgUGVvcGxlIGFyZSBqdXN0IGdvaW5n IHRvIGF2b2lkIGVuYWJsaW5nIGl0DQoJYmVjYXVzZSB3aGVuIHlvdSBkbyBldmVyeXRoaW5nIGJy ZWFrcy4gIEFzIGl0IHN0YW5kcyB0b2RheSB0aGUgZ2VuZXJhbA0KCWNvbnNlbnN1cyBpcyAiZGlz YWJsZSBqdW1ib2dyYW1zLCBjb3ogZXZlbiBpZiB5b3UgbWFuYWdlIHRvIGdldCBpdCBhbGwNCgl3 b3JraW5nIHRvZGF5LCBzb21ldGhpbmcgd2lsbCBjaGFuZ2UgdG9tb3Jyb3cgYW5kIHlvdSdsbCBo YXZlIGEgbmFzdHkNCglwcm9ibGVtIHRvIGZpeCIuDQoJDQoJSWYgYSBzaW1wbGUgc29sdXRpb24g Y2FuIGJlIGZvdW5kIHRvIGhhdmluZyBvbmUgbGluayBzdXBwb3J0IG11bHRpcGxlDQoJTVRVJ3Mg dGhlbiB0aGF0cyB3aGVyZSBJIHRoaW5rIHdlIHNob3VsZCBiZSBoZWFkaW5nIDopICBJZiBvbmUg Y2FuJ3QgYmUNCglmb3VuZCwgdGhlbiB3ZSBzaG91bGQgaW52ZXN0aWdhdGUgd2hhdCB3ZSBjYW4g ZG8gdG8gbWFrZSB0aGlzIGFzIGVhc3kgYXMNCglwb3NzaWJsZSBmb3IgZW5kIHVzZXJzLg0KCQ0K CQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoJSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQoJ aXB2NkBpZXRmLm9yZw0KCUFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgkNCg0K --===============0929748324== 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 -------------------------------------------------------------------- --===============0929748324==-- From ipv6-bounces@ietf.org Tue Jul 26 10:23:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQL0-0003qp-Ch; Tue, 26 Jul 2005 10:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQKx-0003qF-Em; Tue, 26 Jul 2005 10:23:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22268; Tue, 26 Jul 2005 10:23:13 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxQq0-0005wc-Nq; Tue, 26 Jul 2005 10:55:22 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:4819:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C8ED71521A; Tue, 26 Jul 2005 23:22:49 +0900 (JST) Date: Tue, 26 Jul 2005 23:22:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org, dhcwg@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello, I've (re)read the whole big thread on the recent discussion about the RA M/O flags starting at around end of May. We even had a meta-level discussion about whether those flags might better be removed altogether (again!), but it looks we agreed that we need at least some kind of indication in RA. While opinions on the details so varied, we seem to have agreed that we need to fix the requirements for those flags (or something similar/replacement in RA) first. Based on a nice initial attempt by Ralph... http://www1.ietf.org/mail-archive/web/ipv6/current/msg05141.html ...I'd summarize the requirements raised in the thread as follows: 1) Ability to indicate to a host "DHCP is not available on this link", with the expectation that the host won't send any DHCP messages 1') Some people (one person?) also wanted the ability to indicate to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not available on this link" (This is probably a combination like M=0&&O=1 would currently indicate) 2) Ability for a host to get all desired and available DHCP configuration with a single DHCP message exchange - if a host wants HCB, it sends an HCB request (Solicit) and receives HCB and/or ICB replies - if a host wants ICB, it sends an ICB request (Information-request) and receives ICB replies 3) Ability to do DHCP without having to configure routers (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or ICB anyway) Am I missing anything? Note that I'm not saying we need all of them; I'm currently trying to list all major points raised in the past discussion. Some of those may turn out to be a non-requirement. Once we can fix the list, we'll then start the main discussion of which is really necessary and how to do that. (And I'd like to not start that type of discussion at the moment so that we can move forward step-by-step, avoiding further confusion or divergence). 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 Jul 26 10:40:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQbq-0008Nc-RG; Tue, 26 Jul 2005 10:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQbo-0008NU-3t for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 10:40:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24254 for ; Tue, 26 Jul 2005 10:40:38 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxR6r-0006e9-Ly for ipv6@ietf.org; Tue, 26 Jul 2005 11:12:47 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:4819:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6FBCA15218; Tue, 26 Jul 2005 23:40:37 +0900 (JST) Date: Tue, 26 Jul 2005 23:40:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: margaret@thingmagic.com User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipv6@ietf.org Subject: current status about draft-ietf-ipv6-rfc2462bis-08.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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello, Particularly in the case of a dead-lock, may I ask the current status of draft-ietf-ipv6-rfc2462bis-08.txt? According to the I-D tracker page, https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=draft-ietf-ipv6-rfc2462bis-08.txt&search_rfcnumber=&search_area_acronym=&search_button=SEARCH this document is in the AD follow-up state. I thought this version addressed all IESG comments, and wg chairs clarified that the only possibly open issue (regarding implementation report) should not be a non issue for this document: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04938.html Perhaps you are just waiting for the next version of (rfc)2461bis (to be submitted to the IESG) so that the documents will be as much consistent as possible. If so, I'm fine. But if I miss something which I'm expected to do, please let me know. Thanks, 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 Jul 26 11:17:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRB4-0000Xi-O0; Tue, 26 Jul 2005 11:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRB3-0000XB-A4; Tue, 26 Jul 2005 11:17:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26964; Tue, 26 Jul 2005 11:17:03 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxRg7-0007jd-60; Tue, 26 Jul 2005 11:49:12 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6QFHRk0002644 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 26 Jul 2005 17:17:28 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <2C62B9CA-FE3A-4181-9EB4-B0F68714F779@muada.com> Content-Transfer-Encoding: quoted-printable From: Iljitsch van Beijnum Date: Tue, 26 Jul 2005 17:16:46 +0200 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_00,BODY_8BITS, ILJQX_TO_UTF8 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 26-jul-2005, at 16:22, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: > ...I'd summarize the requirements raised in the thread as follows: > 1) Ability to indicate to a host "DHCP is not available on this link", > with the expectation that the host won't send any DHCP messages > 1') Some people (one person?) also wanted the ability to indicate > to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not > available on this link" (This is probably a combination like > M=3D0&&O=3D1 would currently indicate) > 2) Ability for a host to get all desired and available DHCP > configuration with a single DHCP message exchange > - if a host wants HCB, it sends an HCB request (Solicit) and =20 > receives > HCB and/or ICB replies > - if a host wants ICB, it sends an ICB request (Information-=20 > request) > and receives ICB replies > 3) Ability to do DHCP without having to configure routers > (e.g., by ignoring RA with M=3D0 and/or O=3D0 and invoking HCB = and/or > ICB anyway) Can't remember HCB and ICB stand for right now, so maybe I'm missing =20 some of the finer points... Anyway, I believe it's important that clients know that they should =20 ask for addresses + other info over DHCPv6, or other information =20 only. (I'll be happy to explain why at length in private email or in =20 person next week if anyone cares.) Someone implmenting or deploying DHCPv6 would probably want to know =20 whether they should have stateful or stateless servers or both, and =20 stateful or stateless clients or both. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 11:35:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRT3-0005g6-Md; Tue, 26 Jul 2005 11:35:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRT2-0005fw-J1 for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 11:35:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28346 for ; Tue, 26 Jul 2005 11:35:38 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxRy4-0008K3-Ek for ipv6@ietf.org; Tue, 26 Jul 2005 12:07:47 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j6QFYno28385; Tue, 26 Jul 2005 17:34:49 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j6QFYmmE083268; Tue, 26 Jul 2005 17:34:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200507261534.j6QFYmmE083268@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ryota Hirose In-reply-to: Your message of Mon, 25 Jul 2005 19:02:09 +0900. <20050725.190209.179824639.hirose@comm.yamaha.co.jp> Date: Tue, 26 Jul 2005 17:34:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: I think there are three ways for us. 1) Do nothing. Jumbo Frames is an illegal specification for IEEE 802.3, and there is no de facto frame size also. Wait until IEEE will move, or a de facto standard will be made. => this is not acceptable because jumbo frames are too good for performance (two years ago I discover my FreeBSD (again :-) TCP ran at a speed proportional to the frame size up to ~1Gbits/s). 2) Make a new protocol for MTU/MRU discovery/negotiation. Thanks for Mark, Iljitsch or others. => I disagree: this should be the job of IEEE, not the IETF or the IPv6 WG one. 3) Make a memorandum for Jumbo Frames with current implementations. Fix the implicit maximum value of RFC2464, how to enable Jumbo Frames for IPv6, the estimated problems, the implimentation restrictions, and so on. => I vote for this. In fact, it seems we have only/first to fix the wording, i.e., to replace the default MTU from the standards by the default MTU configured on the interface, haven't we? Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 11:49:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRg6-0000JD-C0; Tue, 26 Jul 2005 11:49:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRg4-0000GG-2I for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 11:49:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29205 for ; Tue, 26 Jul 2005 11:49:05 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxSB9-0000JD-3M for ipv6@ietf.org; Tue, 26 Jul 2005 12:21:15 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6QFnak0003166 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 26 Jul 2005 17:49:36 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20050726223620.6154d8f4.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com> <6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com> <20050726121143.53648467.ipng@69706e6720323030352d30312d31340a.nosense.org> <2A8C4AFD-E882-4644-84F2-2B5E4089FD06@muada.com> <20050726223620.6154d8f4.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81DAA628-7CB9-4B3C-A337-997B1C54F537@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Tue, 26 Jul 2005 17:48:54 +0200 To: Mark Smith X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Mark, It's clear that we're thinking from two very different starting points. You want to make a few very small changes to the current way of using jumboframes, all the while accepting all the current limitations that make that virtually nobody uses them. What I want to do is remove the limitations so jumboframe capability will be used whenever it's available. On 26-jul-2005, at 15:06, Mark Smith wrote: > There are probably a few RA announced-style MTU values that need to be > distributed around : > (a) the original MTU that is currently in RAs - the "whole of link" > one. > This is the MTU that all nodes on the link must be capable of > receiving, > as it will be used as the maximum size for multicasts. Right. We leave this one alone. > (b) the "link maximum jumbo" ie. the absolute largest MTU that the > layer > 2 infrastructure can support. Yes. > (I think I've read that some Intel GigE NICs can support 16K > jumbos). I was once testing switches from a vendor we hadn't used before, and I complained that they didn't support jumboframes. A few days later the rep came by again with a card that supported 64000 byte frames. :-) > This value would be configured on the routers making RA > announcements after the layer 2 infrastructure has been had jumbo > frame > capability enabled. Yes, except that it would be even better to have _switches_ announce this value since they're the ones that know it, which means a new message type. >> - validation that jumboframes indeed work to minimize the impact of >> misconfiguration > Once your layer 2 infrastructure is known to support a specific jumbo > frame size, I don't think it is all that necessary to check for it > anymore. People can hook up extra layer 1 or layer 2 devices to your jumbo- capable switch. It's nice if that doesn't bring down the network. > The overheads of checking for it all the time may be too high > when compared to how often unauthorised standard MTU or unconfigured > switches are plugged in to the network. One extra packet in each direction whenever an ND exchange takes place doesn't seem excessive, especially on gigabit ethernet. Remember that we routinely encrypt untold terabytes of data on the off-chance that someone may look at it some time. >> Autoconf is the word, is the word that you heard. It's got groove, >> it's got meaning. Autoconf is the time, is the place is the >> motion. Autoconf is the way we are feeling. > The problem is going too far with the goal of PnP, and then ending > up with > monsterously complex solutions that attempt to address every possible > scenario, including the most esoteric onces, rather than just the > common ones > (ie. common operational scenarios, common failure scenarios). "There is no way anyone will be using this software by the year 2000 anyway..." All of this really isn't very complex. All that's needed is: Simple switches: - periodically multicast a packet with fixed content Routers and managed switches: - accept a user configured value for each interface and multicast an IPv6 packet containing that value Jumboframe capable hosts and routers: - listen for a new type of message to learn link jumbo MTU - whenever such a message is received, see if it's lower or equal to the current stored value, update timestamp - remove stored jumbo MTU for an interface when it's not refreshed in the last N seconds - update IPv6 MTU for interface based on learned jumbo MTU / local maximum - put current IPv6 MTU in neighbor advertisements/solicitations - when receiving neighbor advertisement/solicitation containing jumbo MTU option, send test packet at mimimum of local/remote jumbo MTU - when receiving test packet, update IPv6 MTU for neighbor - when NUD is triggered, update IPv6 MTU for neighbor to regular IPv6 link MTU This is a very simple implementation that doesn't handle lost packets and optimizing for the largest possible jumboframe size, but it should work well enough. > Don't get me wrong, I'd like this solution to be developed. I'm just > wondering how hard it might be to develop, and if there is simpler > interrim "sub-solution" that would still be useful to a fair number of > people, namely those who don't expect to just "plug-and-play" when > they > want to use non-standard protocol parameters and feature, such as > jumbo > frames. > Once a fully fledged "cope with any MTU" solution exists, then > manufacturers of NICs and switches could enable jumbo frames by > default. No, this is exactly the wrong thing to do. The overhead of making ANY change is so huge that it's really not worth it unless you get it right. Also, there often isn't a second chance. Getting things right the first time in actual deployment is very important. Iljitsch -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 11:50:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRhT-0000aw-3B; Tue, 26 Jul 2005 11:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRhR-0000ZU-LE for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 11:50:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29369 for ; Tue, 26 Jul 2005 11:50:31 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxSCT-0000Lv-MV for ipv6@ietf.org; Tue, 26 Jul 2005 12:22:41 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA09545; Tue, 26 Jul 2005 08:49:50 -0700 (PDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6QFnos27868; Tue, 26 Jul 2005 08:49:50 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Jul 2005 08:49:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Jul 2005 08:49:41 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4F59@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: jumbo frame of GbE and IPv6 Thread-Index: AcWR0jkFGegb5ynSSS28AhVIkmCgVAAJqRxg From: "Templin, Fred L" To: "Iljitsch van Beijnum" , "Mark Smith" X-OriginalArrivalTime: 26 Jul 2005 15:49:42.0037 (UTC) FILETIME=[A32BD450:01C591F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 Mailing List Subject: RE: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Iljitsch, > > Matt Mathis in > > draft-ietf-pmtud-method-04.txt and Fred Templin in > > draft-templin-ipvlx-02.txt. >=20 > I don't really see how those apply. They apply in any case where IPv6-in-IPv4 virtual links are used instead of native IPv6 links. Where are we at in the decision process for native IPv6 vs tunneled? 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 Jul 26 12:15:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxS58-0008TS-No; Tue, 26 Jul 2005 12:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxS56-0008Qo-2F for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 12:15:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02424 for ; Tue, 26 Jul 2005 12:14:57 -0400 (EDT) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxSa8-0001ch-Im for ipv6@ietf.org; Tue, 26 Jul 2005 12:47:07 -0400 Received: from dax (ip178.post-vineyard.dfw.ygnition.net [66.135.181.178]) by ns2.sea (8.13.4/8.12.5) with SMTP id j6QGEQOJ031341; Tue, 26 Jul 2005 09:14:26 -0700 Message-ID: <00b001c591fd$1bdaba80$6701a8c0@dax> From: "Stephen Sprunk" To: "Mark Smith" , "Iljitsch van Beijnum" References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><6.2.1.2.2.20050722130807.02d9f8f8@mailhost.iprg.nokia.com><6.2.1.2.2.20050723165502.02dca588@mailhost.iprg.nokia.com><20050726121143.53648467.ipng@69706e6720323030352d30312d31340a.nosense.org><2A8C4AFD-E882-4644-84F2-2B5E4089FD06@muada.com> <20050726223620.6154d8f4.ipng@69706e6720323030352d30312d31340a.nosense.org> Date: Tue, 26 Jul 2005 10:48:39 -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.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thus spake "Mark Smith" > On Tue, 26 Jul 2005 13:05:31 +0200 > Iljitsch van Beijnum wrote: >> You mean: if I hook up two hosts that support 9k jumboframes to a >> cheap unmanaged 10/100 switch (all out of the box) and it doesn't >> work, I have to go in and reconfigure the hosts so it does work? >> >> Sorry, but that's not acceptable. >> > > I think that is an uncommon scenario. How many hosts with jumbo > frame capable interfaces come with jumbo frame capablility _enabled > by default_ ? They can't today according to the existing RFC. What we're proposing is a solution that works in any environment with zero configuration so that jumbos _can_ be enabled by default. > The complex "cope with any MTU on any device" > solution is really trying to address what I think would currently be the > worst case scenario. I don't think that scenario will be all that > common, at least in the short to medium term because : > > (a) devices that are jumbo frame capable don't come with them enabled > by default > > (b) people who enable jumbo frames usually know what they're doing and > what is required for them to work ie. a layer 2 infrastructure that will > support them. Neither of these statements (and the snipped discussion that follows) fit the model some of us are targeting, i.e. Joe Sixpack plugging a bunch of stuff together at home. IMHO, he should get the benefit of jumbos when possible even if he has no clue what "IP" means, much less "jumbo frames". And, I hate to point it out, but even many "professional" admins out there fall into the Joe Sixpack category. >> What we need in addition to this would be (as outlined in my >> message to Bob): >> >> - a mechanism to distribute the MTU for the layer 2 network to >> jumbo-capable systems > > There are probably a few RA announced-style MTU values that need > to be distributed around : > > (a) the original MTU that is currently in RAs - the "whole of link" one. > This is the MTU that all nodes on the link must be capable of receiving, > as it will be used as the maximum size for multicasts. Not really > necessary for ethernets as this value would normally be 1500 bytes, > although there are some uses for ethernets if all offlink destinations > are via a link with a slightly smaller MTU e.g., and IPsec tunnel, to > avoid a PMTUD cycle. The other reason to specifically set it is to cope > with layer 2 technologies such as token ring which don't have a > standardised MTU. I think I'd name this "link multicast MTU" or "link minimum MTU" and I'd default it to 1280 on all media types unless a larger value was advertised (remember, there may not be a router on all networks, and many routers won't implement jumbos at all). > (b) the "link maximum jumbo" ie. the absolute largest MTU that the > layer 2 infrastructure can support. Nodes that can support jumbo > frames can raise their MTU up to either the maximum MTU they > support above the standard value that is less than this value (eg 7k if > they don't support 9K jumbos (they exist, even in fast ethernet. My > Netgear Fa312s under Linux support MTUs of 2024 bytes !)) or set > their MTU to this value, which may actually be smaller than the > jumbo size they're capable of supporting (I think I've read that some > Intel GigE NICs can support 16K jumbos). This value would be > configured on the routers making RA announcements after the layer > 2 infrastructure has been had jumbo frame capability enabled. I'd call this "link maximum MTU", which would be used to constrain the upper bound of the MTU search space. The upper bound might also be constrained by a host with a lower hardware MTU. In the case where there's no router sending such an advertisement, the upper bound would equal the host's hardware MTU. Note that in all cases, a host's MRU should always be the maximum that the hardware supports. It's only the mcast and per-neighbor MTUs that are lower. "Be liberal in what you accept" and all that. >> - validation that jumboframes indeed work to minimize the impact of >> misconfiguration > > Once your layer 2 infrastructure is known to support a specific jumbo > frame size, I don't think it is all that necessary to check for it > anymore. The overheads of checking for it all the time may be too high > when compared to how often unauthorised standard MTU or unconfigured > switches are plugged in to the network. Methinks you overestimate (a) the number of cases where the "admin" knows the MTU, and (b) the odds that what they "know" is correct, either immediately or after a couple years of maintenance. I don't think a probing scenario is avoidable, unfortunately. If people make one small mistake and the hosts don't detect and work around it, the network fails; people will learn that jumbos "don't work" and rarely use them. And, if you start with the assumption you need to probe, the solution becomes more obvious and the problems you can solve become more interesting and compelling. > Don't get me wrong, I'd like this solution to be developed. I'm just > wondering how hard it might be to develop, and if there is simpler > interrim "sub-solution" that would still be useful to a fair number of > people, namely those who don't expect to just "plug-and-play" when > they want to use non-standard protocol parameters and feature, > such as jumbo frames. > > Once a fully fledged "cope with any MTU" solution exists, then > manufacturers of NICs and switches could enable jumbo frames by > default. And at least some of us appear to be trying to solve the larger problem now instead of addressing it in two stages as you propose. I don't like the idea of half-solutions because it delays getting to the real goal, and the interim step seems just as bad if not worse than the status quo. >> > Matt Mathis in draft-ietf-pmtud-method-04.txt and Fred Templin >> > in draft-templin-ipvlx-02.txt. >> >> I don't really see how those apply. > > Only because from what I remember of Matt's draft, and what Fred > said about his, they perform some sort of MTU discovery without > relying on a feedback mechanism e.g. ICMP Dest Unreachable, > Packet Too Big, which I think you solution would have to deal with, > assuming that there wasn't a requirement to add protocols to the > switches. Any solution which requires an upgrade of all the L1/L2 devices in a path will fail in the majority (IMHO) of cases. Let's stick to smart edges and dumb networks. 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 Tue Jul 26 12:47:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSaB-0002Cz-57; Tue, 26 Jul 2005 12:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSaA-0002Cu-0l for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 12:47:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04742 for ; Tue, 26 Jul 2005 12:47:03 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxT5F-0002fn-9x for ipv6@ietf.org; Tue, 26 Jul 2005 13:19:14 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6QGlIk0004033 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 26 Jul 2005 18:47:19 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <42E622A7.8040206@coders.net> References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> <42E25E62.2010805@coders.net> <17E800F8-AAFF-4B67-8CF9-42CB69038694@muada.com> <42E394B2.5020409@coders.net> <42E622A7.8040206@coders.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FA56653-D119-47C2-8434-BE0D32C8182B@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Tue, 26 Jul 2005 18:46:37 +0200 To: Perry Lorier X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 26-jul-2005, at 13:46, Perry Lorier wrote: >>> 6. Minimise the resources used. >> Agree, except that packets are cheap on a 1000 Mbps LAN, so those >> don't >> count much towards 6. > Packet rate however starts becoming a problem at faster speeds, at > gige > it starts becoming a problem for hosts to deal with unless they are > careful. And not all networks are fast, 3G networks are becoming more > prevalent. We should not waste resources needlessly :) Well, the places where jumboframes are worth the trouble are also the places where a handful of packets won't make a difference. I'm not sure how fast 3G is, but I believe not more than a few Mbps, so jumboframes really aren't very useful there because they occupy the channel for too long. Doubly so on radio networks with their high bit error rates. >>> What happens on l2's where not every node can see every other node? >> Neighbor discovery fails? > Host A can talk to Host B ok. > Host A can talk to Host C ok. > Host B can't talk to Host C. > This happens in ad hoc wireless networks. With your system I'm not > entirely sure how you deal with who's "turn" it is next if not all > nodes > can see all other nodes. Host A should still be able to talk to > Host B. Well, a simple way to decide could be a log of the difference in MAC address. So after host 20 sends its packet, host 28 would wait for 3 seconds and host 36 for 4 seconds. But host 36 hears host 28 and resets its timer to 3 seconds. If hosts 28 and 36 can't hear each other, host 36 will send its packet 1 second after host 28 rather than 3 seconds. No big deal. >>> If A and B are talking to each other and C and D are talking to each >>> other, why do (A and B) need to talk to C and D? >> Ah, but how do you know that A doesn't talk to D, and is never >> going to? > How do you know it will in the time before the topology of the network > changes? Given that the topology of the network changes every time a > host comes and goes, the chance that you'll want to talk to most of > the > users during time is rather low. Look at it this way: if two routers send out RAs every 10 seconds, that's one packet every 5 seconds. If 60 hosts all send one packet every five minutes, that's also one packet every 5 seconds. > I'd start at the minimum "MTU" size. Yes, I thought about this and first trying a 1508 byte packet makes sense: if jumboframes don't work, you've wasted as little time and bandwidth as possible. If they do work, you've only wasted 1508 bytes. > A colleague of mine (Matthew Luckie) has done some research into path > MTU's. He has a work in progress paper ( > http://www.wand.net.nz/~mjl12/debugging-pmtud.pdf ) where he > enumerates > all the common MTU's he's seen on the Internet. And reaches a very interesting conclusion! Exchanging per-neighbor MTUs would really help here. > I'd start with a similar table trying the lowest size, and sending > that, > if it's received try the next lowest size and so on until you don't > get > a reply. When you don't get a reply try the previous-mtu-that- > worked+1, > if that succeeds start a binary search between previous-mtu-that- > worked > and the one that didn't. I partially agree. If you're at a well known boundary and want to search upward, it makes sense to try that well known boundary + minimum increment (I say: 4) first. That way, if you can't go beyond the current boundary, you know so immediately. Next is the highest possible value. If you can use that one, you're done. But if previous low + minimum works but maximim doesn't, a mostly binary search still makes sense. However, it could be a "hinted" binary search. For instance, if you're searching between 1508 and 9000 (with the target being 4464) a strict binary search would do: 1 1508 yes 2 9000 no 3 5252 no 4 3380 yes 5 4316 yes 6 4784 no 7 4548 no 8 4432 yes 9 4488 no 10 4460 yes 11 4472 no 12 4464 yes 13 4468 no A hinted binary search could be: 1 1508 yes 2 9000 no 3 4470 no (closest value to binary 5252 target) 4 2048 yes (closest value to binary 2988 target) 5 2052 yes (see if 2048 was our limit) 6 4352 yes (closest value to binary 3260 target) 7 4356 yes (see if 4352 was our limit) 8 4464 yes (closest value to binary 4412 target) 9 4468 no (4464 was our limit) Note that although the second variant is faster overal, the first one finds a reasonable candidate (that can already be used at that point) at try 5, and the second one at try 6. In this case your serial bottom-to-top search would probably be a bit faster, but it has two disadvantages: it takes a long time to find a high MTU, and it's not good at finding non-standard MTUs. > For a "common" MTU, you only have to endure two timeouts (the next > highest common MTU, and the +1 test). For an uncommon MTU you can > increase the MTU to maximum "common" MTU that's lower than your MTU > quickly, and can endure the timeouts from then on. Note that with a 100 ms timeout (more than enough) you're done in less than 2 seconds worst case. >> So when system A tries with 3000 bytes (worked with C!) towards B, >> B sets an >> ack flag and tries with 9216, which fails, so A sends a NAK and tries >> with 6108, and so on. > Hang on, if they don't receive a packet, how can they know to send a > NAK? if they're just waiting for a timeout how can they know if the > packet got lost on the way there or on the way back? Good question. :-) > If instead of using special "ICMP MTU Probes" we use "ICMP Echo > request" > /"ICMP Echo Reply" messages, there is no changes to any packet formats > needed, all it needs to be done is have implemented in a TCP/IP stack, > and the concept is even reusable for IPv4. Other hosts don't even > have > to be upgraded to support this either. magic! You mean, rely just on ICMP and not announce a bigger MTU in RAs? I guess you're right, but I wouldn't want to be a 10 Mbps host in an otherwise 64k jumbo-enabled network, because all those probes would eat up my bandwidth even though I can't successfully receive them. Also, I think we want to be nicer to on-link probers than off-link ones, especially with these large packets. > Stacks would be free to do as you suggest (doing a binary search) > or as > I suggest (ramp up and do a binary search only as a last resort). Yes, this can be left up to the implementers. > So the general approach would be: > * If a packet arrives from a host that is larger than the cached > MTU for > that neighbour, increase it to the size of the packet arriving. Not sure if we want to do this check for every packet. Also, an attacker could fake the packet in order to do an "MTU attack" on a non-jumbo enabled host. > * When receiving a ND (but not a NS!), and you have no cached MTU for > that neighbour, you start the MTU discovery process (using any > mechanism > for selecting the packet sizes the implementation deems appropriate > (ie, > either yours, or mine, or if someone can come up with a method thats > even better than ours, they could use that!) With an MTU option in it. And why not NS? >> No, the announcement "the switch can handle 4500 bytes" wouldn't have >> anything to do with "I can handle 1500". > Which switch? I live in a flat with 3 other people, we have at > least 4 > devices that act like switches on one segment. (2 switches, a voip > phone (you can daisy chain a PC off it), and an AP). I have no idea > what the maximum MTU of all those switches are If all of those switches announce their MTU, we're in business. On the other hand, if we do an MTU search we don't need this information because we'll find out ourselves. If we don't do an MTU search and the switches don't announce their MTU, you're probably not going to use jumboframes on such a network... >> It would be even better if we could ask the switch what our port >> supports, but I'm not sure how to do this in such a way that a switch >> that doesn't support this protocol floods the request so the results >> are meaningless. > Hrm, so Ethernet has capability negotiation (which is how speed, > duplex, > pause frame support etc is negotiated). I have no idea if it says if > the switch supports jumbo gram, IEEE specs make my head hurt. Autonegotiation only does 16 bits or something like that, no room to include the MTU there. Gigabit does have some in-band stuff like flow control, maybe that can be reused. But you always run the risk that a dumb switch just forwards those packets and screws up the negotiation. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 12:56:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSix-0004Ul-DW; Tue, 26 Jul 2005 12:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSiv-0004UB-SC; Tue, 26 Jul 2005 12:56:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05393; Tue, 26 Jul 2005 12:56:07 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxTDz-0002xf-7D; Tue, 26 Jul 2005 13:28:18 -0400 Received: from impact.jinmei.org (PPP308.air-4x8x.dti.ne.jp [210.170.213.82]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 90B1F15218; Wed, 27 Jul 2005 01:56:02 +0900 (JST) Date: Wed, 27 Jul 2005 01:55:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Iljitsch van Beijnum In-Reply-To: <2C62B9CA-FE3A-4181-9EB4-B0F68714F779@muada.com> References: <2C62B9CA-FE3A-4181-9EB4-B0F68714F779@muada.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Tue, 26 Jul 2005 17:16:46 +0200, >>>>> Iljitsch van Beijnum said: > Can't remember HCB and ICB stand for right now, so maybe I'm missing > some of the finer points... > Anyway, I believe it's important that clients know that they should > ask for addresses + other info over DHCPv6, or other information > only. (I'll be happy to explain why at length in private email or in > person next week if anyone cares.) > Someone implmenting or deploying DHCPv6 would probably want to know > whether they should have stateful or stateless servers or both, and > stateful or stateless clients or both. HCB and ICB are defined in draft-ietf-ipv6-ra-mo-flags-01.txt. In short: HCB: getting address (and possible other) configuration information by Solicit/Advertise/Request/Reply exchanges ICB: getting other configuration than addresses (excluding addresses) by Information-request/Reply exchanges So the above requirement of yours seems to be (almost) identical to the following requirement just represented differently: 1') Some people (one person?) also wanted the ability to indicate to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not available on this link" (This is probably a combination like M=0&&O=1 would currently indicate) 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 Jul 26 13:00:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSmg-0005Ex-Fj; Tue, 26 Jul 2005 13:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSme-0005Ed-DM for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 13:00:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05657 for ; Tue, 26 Jul 2005 12:59:57 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxTHg-00034f-NA for ipv6@ietf.org; Tue, 26 Jul 2005 13:32:08 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA12198; Tue, 26 Jul 2005 09:59:08 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6QGx7v22857; Tue, 26 Jul 2005 11:59: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.211); Tue, 26 Jul 2005 09:59:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Jul 2005 09:59:06 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4F5A@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: jumbo frame of GbE and IPv6 Thread-Index: AcWR/TyP6x+4gghbQTuudHE+/eEirQABCcOQ From: "Templin, Fred L" To: "Stephen Sprunk" , "Mark Smith" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 26 Jul 2005 16:59:06.0766 (UTC) FILETIME=[558B0AE0:01C59203] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: jumbo frame of GbE and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Stephen, =20 > >> > Matt Mathis in draft-ietf-pmtud-method-04.txt and Fred Templin > >> > in draft-templin-ipvlx-02.txt. > >> > >> I don't really see how those apply. > > > > Only because from what I remember of Matt's draft, and what Fred > > said about his, they perform some sort of MTU discovery without > > relying on a feedback mechanism e.g. ICMP Dest Unreachable, > > Packet Too Big, which I think you solution would have to deal with, > > assuming that there wasn't a requirement to add protocols to the > > switches. >=20 > Any solution which requires an upgrade of all the L1/L2=20 > devices in a path=20 > will fail in the majority (IMHO) of cases. Let's stick to=20 > smart edges and=20 > dumb networks. Not sure whether you meant this wrt to the drafts mentioned above, but the PMTUD mechanisms proposed in those drafts operate only at edge nodes close to the end nodes or at the end nodes themselves. 'draft-templin=3Dipvlx-02.txt' goes a bit further in proposing a new encapsulation that would need to be understood by some (but not all) middleboxes on the path. But, this is a separate issue from the PMTUD mechanism and if you don't want to touch any middleboxes you can always apply the PMTUD mechanism proposed in that document to other tunneling mechanisms that use "standard" encapsulations. 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 Jul 26 20:29:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZna-0006DQ-SF; Tue, 26 Jul 2005 20:29:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZnY-00069W-Px for ipv6@megatron.ietf.org; Tue, 26 Jul 2005 20:29:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07186 for ; Tue, 26 Jul 2005 20:29:23 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxaIh-0007c8-FJ for ipv6@ietf.org; Tue, 26 Jul 2005 21:01:36 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6R0NOBp024170 for ; Wed, 27 Jul 2005 03:23:26 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jul 2005 03:29:13 +0300 Received: from l5131412.nokia.com ([172.19.69.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 27 Jul 2005 03:29:13 +0300 Message-Id: <6.2.1.2.2.20050726171729.02c84788@daebe102.noe.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 26 Jul 2005 17:29:02 -0700 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2005 00:29:13.0275 (UTC) FILETIME=[36AD48B0:01C59242] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Bob Hinden Subject: Updated IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The updated agenda for the IPv6 working group session at the Paris IETF. This should include missing items pointed out on the list. Thanks, Bob Hinden & Brian Haberman IPv6 Chairs -------------------------------------------------------------------- Internet Protocol Version 6 WG (IPv6) Tuesday, August 2, 2005 1400-1600 Afternoon Session I Havane -------------------------------------- Introduction, Call for Scribes, Hinden 05 minutes and Agenda Bashing Document Status Haberman 05 minutes Implementation Reports for Haberman 05 minutes Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Goal: Call for implementation reports IPv6 Node Information Queries Haberman 10 minutes Goal: Close open issues draft-ietf-ipngwg-icmp-name-lookups-12.txt IPv6 Address Allocation to End Sites Narten 20 minutes Goal: Discussion draft-narten-ipv6-3177bis-48boundary-00.txt URI Syntax Fenner 10 minutes Goal: Make decision to adopt proposal draft-fenner-literal-zone-01.txt Considerations on M and O Flags of Park 15 minutes IPv6 Router Advertisement Goal: Resolve open issues with draft draft-ietf-ipv6-ra-mo-flags-01.txt IPv6 over IEEE802.16 Kim 10 minutes Goal: New draft, Initial Discussion draft-jin-ipv6-over-ieee802.16-00.txt Network discovery and spoofing detection Pashby 10 minutes Goal: Introduction to drafts Distributing Default Address Selection Fujisaki 10 minutes Policy using DHCPv6 Goal: Discussion draft-fujisaki-dhc-addr-select-opt-00.txt Next Steps for IPv6 w.g. Hinden 15 minutes Advancing core specification to Standard Goal: Discussion -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 20:50:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxa7t-0004CR-Er; Tue, 26 Jul 2005 20:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxa7q-0004BH-L5; Tue, 26 Jul 2005 20:50:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08527; Tue, 26 Jul 2005 20:50:21 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxacy-0008E5-K7; Tue, 26 Jul 2005 21:22:34 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 26 Jul 2005 17:50:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,145,1120460400"; d="scan'208"; a="3530950:sNHT22671424" 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 j6R0oBVu006376; Tue, 26 Jul 2005 20:50:11 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 20:50:10 -0400 Received: from 10.86.242.216 ([10.86.242.216]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Jul 2005 00:50:10 +0000 Received: from localhost.localdomain by email.cisco.com; 26 Jul 2005 20:50:53 -0400 From: Ralph Droms To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2005 20:50:52 -0400 Message-Id: <1122425453.25140.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 Jul 2005 00:50:10.0977 (UTC) FILETIME=[24536110:01C59245] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: [dhcwg] a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Your summary looks right to me... - Ralph On Tue, 2005-07-26 at 23:22 +0900, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81= =94=E5=93=89 wrote: > Hello, >=20 > I've (re)read the whole big thread on the recent discussion about the > RA M/O flags starting at around end of May. We even had a meta-level > discussion about whether those flags might better be removed > altogether (again!), but it looks we agreed that we need at least some > kind of indication in RA. >=20 > While opinions on the details so varied, we seem to have agreed that > we need to fix the requirements for those flags (or something > similar/replacement in RA) first. >=20 > Based on a nice initial attempt by Ralph... >=20 > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05141.html >=20 > ...I'd summarize the requirements raised in the thread as follows: >=20 > 1) Ability to indicate to a host "DHCP is not available on this link", > with the expectation that the host won't send any DHCP messages >=20 > 1') Some people (one person?) also wanted the ability to indicate > to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not > available on this link" (This is probably a combination like > M=3D0&&O=3D1 would currently indicate) >=20 > 2) Ability for a host to get all desired and available DHCP > configuration with a single DHCP message exchange > - if a host wants HCB, it sends an HCB request (Solicit) and receives > HCB and/or ICB replies > - if a host wants ICB, it sends an ICB request (Information-request)=20 > and receives ICB replies >=20 > 3) Ability to do DHCP without having to configure routers > (e.g., by ignoring RA with M=3D0 and/or O=3D0 and invoking HCB and/or > ICB anyway) >=20 > Am I missing anything? Note that I'm not saying we need all of them; > I'm currently trying to list all major points raised in the past > discussion. Some of those may turn out to be a non-requirement. >=20 > Once we can fix the list, we'll then start the main discussion of > which is really necessary and how to do that. (And I'd like to not > start that type of discussion at the moment so that we can move > forward step-by-step, avoiding further confusion or divergence). >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 21:17:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxaY4-0004J1-NX; Tue, 26 Jul 2005 21:17:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxaY1-0004II-RU; Tue, 26 Jul 2005 21:17:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10090; Tue, 26 Jul 2005 21:17:24 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxb3A-0000ZQ-HX; Tue, 26 Jul 2005 21:49:38 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR498UXNCE8WXODO@vaxc.its.monash.edu.au>; Wed, 27 Jul 2005 11:16:09 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F23D9AB543; Wed, 27 Jul 2005 11:16:08 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id D1C264FB06; Wed, 27 Jul 2005 11:16:08 +1000 (EST) Date: Wed, 27 Jul 2005 11:16:08 +1000 From: Brett Pentland In-reply-to: To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Message-id: <42E6E058.5040107@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > 1) Ability to indicate to a host "DHCP is not available on this link", > with the expectation that the host won't send any DHCP messages > > 1') Some people (one person?) also wanted the ability to indicate > to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not > available on this link" (This is probably a combination like > M=0&&O=1 would currently indicate) > > 2) Ability for a host to get all desired and available DHCP > configuration with a single DHCP message exchange > - if a host wants HCB, it sends an HCB request (Solicit) and receives > HCB and/or ICB replies > - if a host wants ICB, it sends an ICB request (Information-request) > and receives ICB replies > > 3) Ability to do DHCP without having to configure routers > (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or > ICB anyway) Are 1) and 3) mutually exclusive, or is the requirement to have some M/O combination that says "There is no DHCP, do not try to find it" and another combination that says "I make so representation about the DHCP status so you're free to have a look for it"? Or have I completely missed the point? Brett. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jul 26 22:02:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxbFE-0007ua-V5; Tue, 26 Jul 2005 22:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxbFD-0007t8-7H; Tue, 26 Jul 2005 22:02:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11942; Tue, 26 Jul 2005 22:02:01 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxbkK-0001bU-Gx; Tue, 26 Jul 2005 22:34:16 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:4819:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 721E61521A; Wed, 27 Jul 2005 11:01:49 +0900 (JST) Date: Wed, 27 Jul 2005 11:01:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brett Pentland In-Reply-To: <42E6E058.5040107@eng.monash.edu.au> References: <42E6E058.5040107@eng.monash.edu.au> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 27 Jul 2005 11:16:08 +1000, >>>>> Brett Pentland said: >> 1) Ability to indicate to a host "DHCP is not available on this link", >> with the expectation that the host won't send any DHCP messages >> >> 1') Some people (one person?) also wanted the ability to indicate >> to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not >> available on this link" (This is probably a combination like >> M=0&&O=1 would currently indicate) >> >> 2) Ability for a host to get all desired and available DHCP >> configuration with a single DHCP message exchange >> - if a host wants HCB, it sends an HCB request (Solicit) and receives >> HCB and/or ICB replies >> - if a host wants ICB, it sends an ICB request (Information-request) >> and receives ICB replies >> >> 3) Ability to do DHCP without having to configure routers >> (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or >> ICB anyway) > Are 1) and 3) mutually exclusive, or is the requirement to have some > M/O combination that says "There is no DHCP, do not try to find it" > and another combination that says "I make so representation about the > DHCP status so you're free to have a look for it"? Or have I completely > missed the point? Requirement 1 simply says "DHCP is not available"; it doesn't say "do not try to find it". So I don't think 1 and 3 are mutually exclusive. Note, however, that we've not fully discussed what these requirements exactly mean, perhaps with RFC2119 keywords (MUST or SHOULD or ...). I think that part is a subject of the next phase of this discussion, where the result may make some combination mutually exclusive. But it's not surprising even if some combinations are (or will be) exclusive. As I said in the first message, I just tried to catch up all requirements from various people we've seen so far, in order to make sure that we don't miss anything at the start point. Succeeding discussion in the second phase may reveal exclusive relationships. (But, again, I don't want to go to that level of discussion at the moment.) 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 Wed Jul 27 03:22:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgEt-0000WF-7b; Wed, 27 Jul 2005 03:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgEr-0000VI-9I; Wed, 27 Jul 2005 03:22:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03393; Wed, 27 Jul 2005 03:21:59 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxgk3-00019y-FM; Wed, 27 Jul 2005 03:54:16 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6R7MZk0015874 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 27 Jul 2005 09:22:36 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <42E6E058.5040107@eng.monash.edu.au> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> Content-Transfer-Encoding: quoted-printable From: Iljitsch van Beijnum Date: Wed, 27 Jul 2005 09:21:55 +0200 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_00,BODY_8BITS, ILJQX_TO_UTF8 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 27-jul-2005, at 4:01, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: >> Are 1) and 3) mutually exclusive, or is the requirement to have some >> M/O combination that says "There is no DHCP, do not try to find it" >> and another combination that says "I make so representation about the >> DHCP status so you're free to have a look for it"? Or have I =20 >> completely >> missed the point? > Requirement 1 simply says "DHCP is not available"; it doesn't say "do > not try to find it". I disagree. On some networks it's inappropriate to try to use DHCPv6. And if hosts are going to look for DHCPv6 servers regardless of the =20 value of the M/O bits, what's the point of this whole discussion??= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 27 03:45:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgbK-0006rI-97; Wed, 27 Jul 2005 03:45:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgbI-0006ql-IT; Wed, 27 Jul 2005 03:45:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04856; Wed, 27 Jul 2005 03:45:10 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxh6V-00026L-4B; Wed, 27 Jul 2005 04:17:28 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 53ABD15218; Wed, 27 Jul 2005 16:44:57 +0900 (JST) Date: Wed, 27 Jul 2005 16:44:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Iljitsch van Beijnum In-Reply-To: <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 27 Jul 2005 09:21:55 +0200, >>>>> Iljitsch van Beijnum said: >>> Are 1) and 3) mutually exclusive, or is the requirement to have some >>> M/O combination that says "There is no DHCP, do not try to find it" >>> and another combination that says "I make so representation about the >>> DHCP status so you're free to have a look for it"? Or have I >>> completely >>> missed the point? >> Requirement 1 simply says "DHCP is not available"; it doesn't say "do >> not try to find it". > I disagree. On some networks it's inappropriate to try to use DHCPv6. You can disagree about anything, but please remember that we are (or at least I'm) currently concentrating on listing points raised so far, without discussing whether each point is valid or not. And, in fact, there has actually been an opposite opinion to yours in the past discussion. Can we hold off expressing opinions on the possible requirements a bit while, please? Otherwise, we'll soon see a strom of different opinions as we've seen in the previous threads. (Such a storm is perhaps inevitable in the next phase of this discussion though). Thanks, 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 Wed Jul 27 03:56:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgmJ-0001W8-UU; Wed, 27 Jul 2005 03:56:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgmH-0001Tf-IZ; Wed, 27 Jul 2005 03:56:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05462; Wed, 27 Jul 2005 03:56:31 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxhHV-0002Rj-77; Wed, 27 Jul 2005 04:28:49 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6R7v9k0016398 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 27 Jul 2005 09:57:10 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Iljitsch van Beijnum Date: Wed, 27 Jul 2005 09:56:29 +0200 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_00,BODY_8BITS, ILJQX_TO_UTF8 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 27-jul-2005, at 9:44, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: >>> Requirement 1 simply says "DHCP is not available"; it doesn't say =20= >>> "do >>> not try to find it". >> I disagree. On some networks it's inappropriate to try to use DHCPv6. > You can disagree about anything, but please remember that we are (or > at least I'm) currently concentrating on listing points raised so far, > without discussing whether each point is valid or not. And, in fact, > there has actually been an opposite opinion to yours in the past > discussion. Hence the discussion. There have also been others who agree with me. =20 The trouble is, that you weakened the requirement by saying "it =20 doesn't say "do not try to find it"." > Can we hold off expressing opinions on the possible requirements a bit > while, please? Otherwise, we'll soon see a strom of different > opinions as we've seen in the previous threads. (Such a storm is > perhaps inevitable in the next phase of this discussion though). Perhaps it's possible to get together in person with a small group of =20= people with strong opinions about the subject to see if there is some =20= way to work all of this out? I really don't see how why this would be =20= unsolvable, but for some reason we can't seem to get past this.= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 27 04:23:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxhC8-0000ZQ-Uo; Wed, 27 Jul 2005 04:23:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxhC6-0000Yn-Bv; Wed, 27 Jul 2005 04:23:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07140; Wed, 27 Jul 2005 04:23:11 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxhhJ-0003Nb-4l; Wed, 27 Jul 2005 04:55:30 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EB1BC15218; Wed, 27 Jul 2005 17:23:07 +0900 (JST) Date: Wed, 27 Jul 2005 17:23:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Iljitsch van Beijnum In-Reply-To: References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 27 Jul 2005 09:56:29 +0200, >>>>> Iljitsch van Beijnum said: >>>> Requirement 1 simply says "DHCP is not available"; it doesn't say >>>> "do >>>> not try to find it". >>> I disagree. On some networks it's inappropriate to try to use DHCPv6. >> You can disagree about anything, but please remember that we are (or >> at least I'm) currently concentrating on listing points raised so far, >> without discussing whether each point is valid or not. And, in fact, >> there has actually been an opposite opinion to yours in the past >> discussion. > Hence the discussion. There have also been others who agree with me. > The trouble is, that you weakened the requirement by saying "it > doesn't say "do not try to find it"." Okay. However, not including the intent of "do not try to find it", while there is the *expectation* that the host won't send any DHCP messages, was actually my understanding of Ralph's original summaryn (http://www1.ietf.org/mail-archive/web/ipv6/current/msg05141.html). If my interpretation was incorrect, I'm happy to be corrected. Even if others, I see some people (one person?) wants to include the stronger implication. So, I'd revise the requirement list as follows: 1) Ability to indicate to a host "DHCP is not available on this link", with the expectation that the host won't send any DHCP messages 1') Some people also wanted to indicate a stronger message of "do not try to find it" in requirement 1. 1'') Some people (one person?) also wanted the ability to indicate to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not available on this link" (This is probably a combination like M=0&&O=1 would currently indicate). [Note: requirement 1'' can also have two variations: with or without the intent of "do not try to find it". But since the "some people" seem to be the same group, there is probably no version of 1'' without the intent] 2) Ability for a host to get all desired and available DHCP configuration with a single DHCP message exchange - if a host wants HCB, it sends an HCB request (Solicit) and receives HCB and/or ICB replies - if a host wants ICB, it sends an ICB request (Information-request) and receives ICB replies 3) Ability to do DHCP without having to configure routers (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or ICB anyway) [Note: this requirement contradicts requirement 1'. We'll need to determine which one should be honored or whether there is an intermediate compromise.] Is this better? 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 Wed Jul 27 05:29:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxiEI-0000HP-MQ; Wed, 27 Jul 2005 05:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxiEG-0000HH-8C; Wed, 27 Jul 2005 05:29:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10562; Wed, 27 Jul 2005 05:29:29 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxijS-0005Qb-UG; Wed, 27 Jul 2005 06:01:49 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j6R9Sei21812; Wed, 27 Jul 2005 12:28:42 +0300 Date: Wed, 27 Jul 2005 12:28:39 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum In-Reply-To: <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> Message-ID: References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dhcwg@ietf.org, IETF IPv6 Mailing List , =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, 27 Jul 2005, Iljitsch van Beijnum wrote: >> Requirement 1 simply says "DHCP is not available"; it doesn't say "do >> not try to find it". > > I disagree. On some networks it's inappropriate to try to use DHCPv6. For the purposes of this (requirements) dicussion, I think it would be useful if you could describe these "some networks" and elaborate why trying to use DHCPv6 would be inappropriate. That would allow us to have more beef to the requirements, for the next steps when we'll evaluate these requirements. -- 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 Jul 27 05:56:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxieC-0007Ah-Ab; Wed, 27 Jul 2005 05:56:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxieA-00079t-BI for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 05:56:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11734 for ; Wed, 27 Jul 2005 05:56:15 -0400 (EDT) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxj9O-0006Ar-HK for ipv6@ietf.org; Wed, 27 Jul 2005 06:28:35 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j6R9u5qQ134398 for ; Wed, 27 Jul 2005 09:56:05 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6R9u5XE144868 for ; Wed, 27 Jul 2005 10:56:05 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j6R9u54w020860 for ; Wed, 27 Jul 2005 10:56:05 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j6R9u4Ja020857; Wed, 27 Jul 2005 10:56:04 +0100 Received: from zurich.ibm.com (sig-9-145-254-247.de.ibm.com [9.145.254.247]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA65232; Wed, 27 Jul 2005 11:56:04 +0200 Message-ID: <42E75A33.3080206@zurich.ibm.com> Date: Wed, 27 Jul 2005 11:56:03 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Templin, Fred L" References: <39C363776A4E8C4A94691D2BD9D1C9A10D4F33@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4F33@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: IPv6 , Bob Hinden Subject: Re: NSAP Address IPv6 option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I haven't seen any more discussion on this. It makes perfect sense to post errata, and as document editor I can do that, but we also need to send a request to IANA, as Bob suggested, and that presumably needs WG consensus to be declared, which is outside my scope. Brian Templin, Fred L wrote: > Why not just post this as errata to RFC4048? > > Fred > > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@nokia.com] > Sent: Monday, July 11, 2005 10:18 AM > To: Brian E Carpenter > Cc: IPv6 > Subject: Re: NSAP Address IPv6 option > > Brian, > > At 07:04 AM 07/11/2005, Brian E Carpenter wrote: > >>RFC 1888 defined a destination option called "NSAP Address" >>with option type code 11-0-00011 = 195 decimal, C3 hexadecimal. >> >>Unfortunately, the IANA Considerations in RFC 4048 >>faild to discuss this option. It is still listed at >>http://www.iana.org/assignments/ipv6-parameters >> >>My opinion is that it can be released; I'm aware of no usage. >> >>Any objections? Can the WG Chairs suggest a procedure to avoid >>the overhead of another trivial RFC? > > > The chairs could send an email to the IANA (with cc's to the IPv6 list > and > IESG) with something to the effect that since RFC4048 made RFC1888 > historic, the destination option defined by RFC1888 is no longer needed > and > should be marked as Reserved. This was the intention of RFC4048, but > was > omitted in error. > > The only downside of this approach I can think of is that there wouldn't > be > an RFC documenting the change. I am not sure this is a big deal in > this case. > > Other opinions and/or suggestions? > > 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 ipv6-bounces@ietf.org Wed Jul 27 06:01:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxij5-0008EA-GQ; Wed, 27 Jul 2005 06:01:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxij2-0008DX-S7; Wed, 27 Jul 2005 06:01:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12061; Wed, 27 Jul 2005 06:01:17 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxjEG-0006Kv-Kf; Wed, 27 Jul 2005 06:33:38 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6RA1tk0018047 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 27 Jul 2005 12:01:56 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43ABEB86-451F-4E97-B8D6-F042FD7FA77A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 27 Jul 2005 12:01:12 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 27-jul-2005, at 11:28, Pekka Savola wrote: >>> Requirement 1 simply says "DHCP is not available"; it doesn't say >>> "do >>> not try to find it". >> I disagree. On some networks it's inappropriate to try to use DHCPv6. > For the purposes of this (requirements) dicussion, I think it would > be useful if you could describe these "some networks" and elaborate > why trying to use DHCPv6 would be inappropriate. It wastes bandwidth, which may be an issue on some link types. (I think someone mentioned 3G here.) It also uses up other resources needlessly, such as multicast slots in NICs. Doing DHCPv6 when there is no legitimate DHCPv6 server makes it easier for attackers to use rogue DHCPv6 servers to inject false configuration information into hosts. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 27 06:55:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxjZ9-000546-Bk; Wed, 27 Jul 2005 06:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxjZ6-000541-Uk for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 06:55:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15036 for ; Wed, 27 Jul 2005 06:55:05 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx2.orcon.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxk4L-0007z3-5K for ipv6@ietf.org; Wed, 27 Jul 2005 07:27:26 -0400 Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx2.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j6RB2rZj010945 for ; Wed, 27 Jul 2005 23:02:55 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1DxjYq-0000XV-00 for ; Wed, 27 Jul 2005 22:54:52 +1200 Message-ID: <42E767FB.5010108@coders.net> Date: Wed, 27 Jul 2005 22:54:51 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050724 X-Accept-Language: en-nz, en MIME-Version: 1.0 CC: IETF IPv6 Mailing List References: <42DE90BC.3050403@nasa.gov><20050721.080152.184461359.hirose@comm.yamaha.co.jp><20050722.103248.35008368.hirose@comm.yamaha.co.jp><20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> <42E25E62.2010805@coders.net> <17E800F8-AAFF-4B67-8CF9-42CB69038694@muada.com> <42E394B2.5020409@coders.net> <42E622A7.8040206@coders.net> <8FA56653-D119-47C2-8434-BE0D32C8182B@muada.com> In-Reply-To: <8FA56653-D119-47C2-8434-BE0D32C8182B@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/994/Wed Jul 27 20:28:09 2005 on dbmail-mx2.orcon.net.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: 7bit Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org [Bugger! Lost the reply I was writing for this! ] >> Packet rate however starts becoming a problem at faster speeds, at gige >> it starts becoming a problem for hosts to deal with unless they are >> careful. And not all networks are fast, 3G networks are becoming more >> prevalent. We should not waste resources needlessly :) > > > Well, the places where jumboframes are worth the trouble are also the > places where a handful of packets won't make a difference. I'm not sure > how fast 3G is, but I believe not more than a few Mbps, so jumboframes > really aren't very useful there because they occupy the channel for too > long. Doubly so on radio networks with their high bit error rates. Good point :) >>>> What happens on l2's where not every node can see every other node? >>> Neighbor discovery fails? >> Host A can talk to Host B ok. >> Host A can talk to Host C ok. >> Host B can't talk to Host C. > >> This happens in ad hoc wireless networks. With your system I'm not >> entirely sure how you deal with who's "turn" it is next if not all nodes >> can see all other nodes. Host A should still be able to talk to Host B. > > Well, a simple way to decide could be a log of the difference in MAC > address. So after host 20 sends its packet, host 28 would wait for 3 > seconds and host 36 for 4 seconds. But host 36 hears host 28 and resets > its timer to 3 seconds. If hosts 28 and 36 can't hear each other, host > 36 will send its packet 1 second after host 28 rather than 3 seconds. > No big deal. Yeah, but if this is happening lots you will end up with lots of hosts transmitting close together. Maybe it's not a problem as you suggest, but I can't help feel that this seems a bit too complicated. >>>> If A and B are talking to each other and C and D are talking to each >>>> other, why do (A and B) need to talk to C and D? > >>> Ah, but how do you know that A doesn't talk to D, and is never going >>> to? > > >> How do you know it will in the time before the topology of the network >> changes? Given that the topology of the network changes every time a >> host comes and goes, the chance that you'll want to talk to most of the >> users during time is rather low. > > Look at it this way: if two routers send out RAs every 10 seconds, > that's one packet every 5 seconds. If 60 hosts all send one packet > every five minutes, that's also one packet every 5 seconds. If they send it in the same 5s tho you'll melt your queues :) How long will this take to converge? Remember that you have to start again as soon as the topology changes (eg a new host is added/removed). The advantage with this part of your scheme is that it does give you MTU's that you can use for multicast. >> I'd start at the minimum "MTU" size. > > Yes, I thought about this and first trying a 1508 byte packet makes > sense: if jumboframes don't work, you've wasted as little time and > bandwidth as possible. If they do work, you've only wasted 1508 bytes. I'd start with 1500; check your assumptions. In fact, it might be worth starting at 1280 and if that fails log a message that the L2 is broken. There are enough networks out there that use various tunnels that the L2 MTU is slightly smaller than you would expect to make it worth while to at least check. >> A colleague of mine (Matthew Luckie) has done some research into path >> MTU's. He has a work in progress paper ( >> http://www.wand.net.nz/~mjl12/debugging-pmtud.pdf ) where he enumerates >> all the common MTU's he's seen on the Internet. > > And reaches a very interesting conclusion! Exchanging per-neighbor MTUs > would really help here. Exactly. :) >> I'd start with a similar table trying the lowest size, and sending that, >> if it's received try the next lowest size and so on until you don't get >> a reply. When you don't get a reply try the previous-mtu-that- worked+1, >> if that succeeds start a binary search between previous-mtu-that- worked >> and the one that didn't. > > I partially agree. If you're at a well known boundary and want to > search upward, it makes sense to try that well known boundary + minimum > increment (I say: 4) first. That way, if you can't go beyond the > current boundary, you know so immediately. Next is the highest possible > value. If you can use that one, you're done. > > But if previous low + minimum works but maximim doesn't, a mostly > binary search still makes sense. However, it could be a "hinted" binary > search. For instance, if you're searching between 1508 and 9000 (with > the target being 4464) a strict binary search would do: > > 1 1508 yes > 2 9000 no > 3 5252 no > 4 3380 yes > 5 4316 yes > 6 4784 no > 7 4548 no > 8 4432 yes > 9 4488 no > 10 4460 yes > 11 4472 no > 12 4464 yes > 13 4468 no > > A hinted binary search could be: > > 1 1508 yes > 2 9000 no > 3 4470 no (closest value to binary 5252 target) > 4 2048 yes (closest value to binary 2988 target) > 5 2052 yes (see if 2048 was our limit) > 6 4352 yes (closest value to binary 3260 target) > 7 4356 yes (see if 4352 was our limit) > 8 4464 yes (closest value to binary 4412 target) > 9 4468 no (4464 was our limit) > > Note that although the second variant is faster overal, the first one > finds a reasonable candidate (that can already be used at that point) > at try 5, and the second one at try 6. > > In this case your serial bottom-to-top search would probably be a bit > faster, but it has two disadvantages: it takes a long time to find a > high MTU, and it's not good at finding non-standard MTUs. Mine would do: 1 1514 yes 2 1536 yes 3 2002 yes 4 2048 yes 5 4352 yes 6 4464 yes 7 4470 no 8 4465 no Now, if you assume a timeout is at least 2 RTT's (and I suspect it should probably be more) mine takes 6RTT's to find the right MTU, and takes 10RTT's to prove it. Your first one takes 19 RTT's to find it and 20 RTT's to prove it. Your second (hinted) one takes 10 RTT's to find it, and 12 RTT's to prove it. As the MTU's get larger yours gets faster (since it is less likely to hit a "no") and mine gets slower. Mine is slow if there is a non standard MTU (which I suspect would be rare, but anyway). But after it's found a non standard MTU it can be added to the table and it'll be found quickly next time. >> For a "common" MTU, you only have to endure two timeouts (the next >> highest common MTU, and the +1 test). For an uncommon MTU you can >> increase the MTU to maximum "common" MTU that's lower than your MTU >> quickly, and can endure the timeouts from then on. > > Note that with a 100 ms timeout (more than enough) you're done in less > than 2 seconds worst case. Yup, but it makes more sense to talk about RTT's than seconds :) >> If instead of using special "ICMP MTU Probes" we use "ICMP Echo request" >> /"ICMP Echo Reply" messages, there is no changes to any packet formats >> needed, all it needs to be done is have implemented in a TCP/IP stack, >> and the concept is even reusable for IPv4. Other hosts don't even have >> to be upgraded to support this either. magic! > > You mean, rely just on ICMP and not announce a bigger MTU in RAs? yeah pretty much. > I guess you're right, but I wouldn't want to be a 10 Mbps host in an > otherwise 64k jumbo-enabled network, because all those probes would eat > up my bandwidth even though I can't successfully receive them. You'd get one probe when you talked to a new host, which would immediately fail. > Also, I think we want to be nicer to on-link probers than off-link > ones, especially with these large packets. Indeed. The problem with probing for large MTU's is that the probes themselves are large :) >> Stacks would be free to do as you suggest (doing a binary search) or as >> I suggest (ramp up and do a binary search only as a last resort). > > Yes, this can be left up to the implementers. > >> So the general approach would be: >> * If a packet arrives from a host that is larger than the cached MTU for >> that neighbour, increase it to the size of the packet arriving. > > Not sure if we want to do this check for every packet. It's a simple test, and besides, you don't have to do it for every every packet, just the packets that matter :) > Also, an > attacker could fake the packet in order to do an "MTU attack" on a > non-jumbo enabled host. Yes, this is a problem, but then again, presumably they can forge the NS reply anyway. All that this means is that you need to sign your packets. >> * When receiving a ND (but not a NS!), and you have no cached MTU for >> that neighbour, you start the MTU discovery process (using any mechanism >> for selecting the packet sizes the implementation deems appropriate (ie, >> either yours, or mine, or if someone can come up with a method thats >> even better than ours, they could use that!) > > With an MTU option in it. yeah that's probably wise, although not necessary. You could probe always and pray. > And why not NS? Because when A talks to B, you want A to do the MTU discovery and for B to "learn" the MTU too, but you don't want both sending MTU probes, only one of them needs to do so. > >>> No, the announcement "the switch can handle 4500 bytes" wouldn't have >>> anything to do with "I can handle 1500". > > >> Which switch? I live in a flat with 3 other people, we have at least 4 >> devices that act like switches on one segment. (2 switches, a voip >> phone (you can daisy chain a PC off it), and an AP). I have no idea >> what the maximum MTU of all those switches are > > > If all of those switches announce their MTU, we're in business. If we're making fanciful wishes, can I have a million dollars? and a pony? While having switches announce MTU's is possible, I don't think you'll get switch manufacturers to agree, and even if they do the old and/or cheap switches won't announce it therefore leaving you to have to probe anyway. and even if all the switches announce their MTU, how do you know which subset of switches your going through to get to the other end? > On the other hand, if we do an MTU search we don't need this > information because we'll find out ourselves. Exactly. > If we don't do an MTU search and the switches don't announce their MTU, > you're probably not going to use jumboframes on such a network... And you fall back to 1280 (or some other link defined minimum such as 1500). >>> It would be even better if we could ask the switch what our port >>> supports, but I'm not sure how to do this in such a way that a switch >>> that doesn't support this protocol floods the request so the results >>> are meaningless. > >> Hrm, so Ethernet has capability negotiation (which is how speed, duplex, >> pause frame support etc is negotiated). I have no idea if it says if >> the switch supports jumbo gram, IEEE specs make my head hurt. > > > Autonegotiation only does 16 bits or something like that, no room to > include the MTU there. Plenty of room for a "1500, small,medium or large jumbo frames" tho :) > Gigabit does have some in-band stuff like flow > control, maybe that can be reused. PAUSE frames yeah, not particularly useful but perhaps doable :) > But you always run the risk that a > dumb switch just forwards those packets and screws up the negotiation. Yup. You want to probe to find out. I'm beginning to think you want to probe Point to point links too to discover if they have any weird limitations that they aren't announcing. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 27 06:58:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxjbx-0005Pk-FT; Wed, 27 Jul 2005 06:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxjbv-0005Pa-SY for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 06:58:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15245 for ; Wed, 27 Jul 2005 06:58:00 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxk7B-00084s-9u for ipv6@ietf.org; Wed, 27 Jul 2005 07:30:21 -0400 Received: by rproxy.gmail.com with SMTP id r35so231895rna for ; Wed, 27 Jul 2005 03:58:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NPgm92zZzSnkz2X3voOqtlhBCRwrsQ5EMfuEXTjo9VPPVhRmafdM+N4ar7VGn4JcU2wrGYLmRWMD5UaF0epgEe5JvhLuD2Z5JyLHhklBoRag4iGJkFDzBtIKqnAFFRfgOJsgD7jpEk5JDJQvXjhisUVD6H4a2G1hv3QgrgArpx4= Received: by 10.38.10.5 with SMTP id 5mr433158rnj; Wed, 27 Jul 2005 03:58:02 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Wed, 27 Jul 2005 03:58:02 -0700 (PDT) Message-ID: <10e14db2050727035827463def@mail.gmail.com> Date: Wed, 27 Jul 2005 16:28:02 +0530 From: Syam Madanapalli To: Iljitsch van Beijnum In-Reply-To: <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List , =?ISO-2022-JP?Q?JINMEI_Tatuya_/_=1B=24B=3F=40L=40C=23=3AH=1B=28B?= Subject: Re: [dhcwg] Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Syam Madanapalli List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The flags are just hints, the host can always ignore them. If it is inappropriate to try to use DHCP when flags are zero, let it be so. Similarly if the flag(s) is (are) set, the host can always ignore. Otherwise we need to say that the M/O flags are triggers of DHCP. So we need to agree if the flags are hints or triggers. -Syam On 7/27/05, Iljitsch van Beijnum wrote: > On 27-jul-2005, at 4:01, JINMEI Tatuya / $B?@L@C#:H(B wrote: > > >> Are 1) and 3) mutually exclusive, or is the requirement to have some > >> M/O combination that says "There is no DHCP, do not try to find it" > >> and another combination that says "I make so representation about the > >> DHCP status so you're free to have a look for it"? Or have I > >> completely > >> missed the point? > > > Requirement 1 simply says "DHCP is not available"; it doesn't say "do > > not try to find it". > > I disagree. On some networks it's inappropriate to try to use DHCPv6. > > And if hosts are going to look for DHCPv6 servers regardless of the > value of the M/O bits, what's the point of this whole discussion?? > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 27 07:02:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxjgW-00078A-SB; Wed, 27 Jul 2005 07:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxjgU-00077b-Vl for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 07:02:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15688 for ; Wed, 27 Jul 2005 07:02:43 -0400 (EDT) Received: from paddock.ermy.net ([62.189.30.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxkBi-0008F2-W2 for ipv6@ietf.org; Wed, 27 Jul 2005 07:35:04 -0400 Received: (qmail 27401 invoked from network); 27 Jul 2005 11:08:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 27 Jul 2005 11:08:12 -0000 Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <10e14db2050727035827463def@mail.gmail.com> References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> <10e14db2050727035827463def@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Mark K. Thompson" Date: Wed, 27 Jul 2005 12:02:30 +0100 To: dhcwg@ietf.org, IETF IPv6 Mailing List X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: Re: [dhcwg] Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 27 Jul 2005, at 11:58, Syam Madanapalli wrote: > Otherwise we need to say that the M/O flags are triggers > of DHCP. So we need to agree if the flags are hints or triggers. I would add that if they are hints, then we are not mandating any signalling between DHCPv6 relays or servers and routers sending RAs. If they are triggers, then I would suggest that we should specify the nature of the tighter coupling of these disparate processes. Mark/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 27 07:13:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxjqr-00020I-84; Wed, 27 Jul 2005 07:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxjqp-000206-MM for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 07:13:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16648 for ; Wed, 27 Jul 2005 07:13:24 -0400 (EDT) Received: from sentinel.cs.cf.ac.uk ([131.251.42.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxkM4-0000Dp-6G for ipv6@ietf.org; Wed, 27 Jul 2005 07:45:45 -0400 Received: from ebrainofcf.cs.cf.ac.uk ([131.251.47.142] helo=ebrainofcf) by sentinel.cs.cf.ac.uk with esmtp (Exim 4.43 #5) id 1DxjqY-0002iR-V3 for ipv6@ietf.org; Wed, 27 Jul 2005 12:13:11 +0100 Message-ID: <002801c5929c$2ccef000$8e2ffb83@ebrainofcf> From: "Dr. Lican Huang" To: References: <2C62B9CA-FE3A-4181-9EB4-B0F68714F779@muada.com> Date: Wed, 27 Jul 2005 12:13:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response 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: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: about distributed 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, I plan to use p2p protocol(VIRGO) I proposed to build distributes DNS. VIRGO contains an n-tuple replicated virtual tree structured network that differs from DHT-based P2P networks and random unstructured networks cached by least-recently used (LRU) and minimum difference (MinD) replacement strategies. The details about VIRGO can be view in the paper at: http://dx.doi.org/10.1007/11508380_93 . In this distributed DNS, there are no centralized DNS server. The LRU and MinD cached route tables avoids message overload in specific nodes. Duplicated gateway nodes keeps the virtual tree topology all the time. Could any one give any comments about it? Thanks in advance Best regards, Dr Lican Huang Computer Science, Cardiff University, Queen's Buildings, 5 The Parade, Roath, Cardiff CF24 3AA, UK Email: Lican.Huang@cs.cardiff.ac.uk Tel: +44 (0) 29 20879184 Fax: +44 (0) 29 20874598 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 27 08:00:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxkZy-00073B-CM; Wed, 27 Jul 2005 08:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxkZv-00072U-Da for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 08:00:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20289 for ; Wed, 27 Jul 2005 08:00:01 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxl5A-00026I-Tt for ipv6@ietf.org; Wed, 27 Jul 2005 08:32:21 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 74BC415218; Wed, 27 Jul 2005 21:00:00 +0900 (JST) Date: Wed, 27 Jul 2005 21:00:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: fujisaki@syce.net In-Reply-To: <20050723.140110.115902850.fujisaki@syce.net> References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> <20050723.140110.115902850.fujisaki@syce.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ipv6@ietf.org Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Sat, 23 Jul 2005 14:01:10 +0900 (JST), >>>>> fujisaki@syce.net said: > | Here is the first cut at an agenda for the IPv6 working group session at > | the Paris IETF. Please review and send us comments, deletions, and additions. > Could you please give me a few minutes for following draft? > Title: Distributing Default Address Selection Policy using DHCPv6 > Filename: draft-fujisaki-dhc-addr-select-opt-00.txt > As a result of a discussion at last IETF dhc wg, I need ipv6 wg > support to move forward this draft. I've read the latest draft, but I'm afraid the document itself doesn't help assess whether the ipv6 wg can support that or not, since it mainly concentrates on the DHCPv6 specific issues. I believe what should be discussed in this group is the intended scenarios (the "Practical Usage" section) described in this URL: > As I posted before, this draft describes the RFC3484 policy table > distribution (please refer http://www.nttv6.net/dass). I've read this page, too. My current impression is that "I see some point, but I'm not sure if it's enough for introducing a new DHCPv6 option". Specifically, > Case1: IPv4 or IPv6 Prioritization I see this is a case where the automatic policy distribution may help. But since the address selection by RFC3484 is much more powerful than just selection between IPv4 and IPv6, I don't think this can be a convincing usage if this is the only meaningful case. > Case2: ULA or Global Prioritization > Case3: Multicast Source Address Selection For these cases, using a non default policy table could resolve the issue (and automatic policy distribution would help), but I personally think this should be rather dealt with through a clarification for the "default" selection rule, with the fact that site-local unicast addresses were deprecated and ULAs are introduced. > Case4: Global and Closed Mixed Connectivity This may look a valid use case superficially, but people will actually wonder why ISP2 needs (or can have) global (non ULA) addresses, or even any IPv6 addresses, to begin with, if it's not connected to the global Internet. And, for example, if the closed network uses ULAs and we clarify the "default" address selection policy, we'll be just happy with the clarified default policy (we may also need the new '/54' allocation policy as well, though). Or, if ISP2 just uses private IPv4 addresses, we'll just be happy even with the current default rules. Unless the usage example answers to this natural question, I'm afraid this will look artificial (and thus cannot be convincing). 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 Wed Jul 27 08:23:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxkwL-00058i-Dp; Wed, 27 Jul 2005 08:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxkwK-00058d-4C for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 08:23:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22338 for ; Wed, 27 Jul 2005 08:23:10 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxlRX-0002yH-VM for ipv6@ietf.org; Wed, 27 Jul 2005 08:55:30 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6RCN1HG006189; Wed, 27 Jul 2005 14:23:01 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j6RCN1Et003375; Wed, 27 Jul 2005 14:23:01 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j6RCN13q003374; Wed, 27 Jul 2005 14:23:01 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 27 Jul 2005 14:23:01 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20050727122301.GC3064@storhaugen.uninett.no> References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> <20050723.140110.115902850.fujisaki@syce.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ipv6@ietf.org, fujisaki@syce.net Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, Jul 27, 2005 at 09:00:00PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Sat, 23 Jul 2005 14:01:10 +0900 (JST), > >>>>> fujisaki@syce.net said: > > > | Here is the first cut at an agenda for the IPv6 working group session at > > | the Paris IETF. Please review and send us comments, deletions, and additions. > > > Could you please give me a few minutes for following draft? > > > Title: Distributing Default Address Selection Policy using DHCPv6 > > Filename: draft-fujisaki-dhc-addr-select-opt-00.txt > > > As a result of a discussion at last IETF dhc wg, I need ipv6 wg > > support to move forward this draft. > > I've read the latest draft, but I'm afraid the document itself doesn't > help assess whether the ipv6 wg can support that or not, since it > mainly concentrates on the DHCPv6 specific issues. > > I believe what should be discussed in this group is the intended > scenarios (the "Practical Usage" section) described in this URL: Yes, I believe the most important know is whether such an option is useful or not. So one question is how common it will be to have non- default policies. Another is how it might be autoconfigured. If a site has a large number of clients that needs a non-default policy, then some way of distributing that policy to the clients is needed. There are also some technical issues, but those can perhaps be discussed later. Mainly how to represent the different values like precedence, label, scopeid etc. 3484 doesn't really describe the datatypes in detail. E.g. zone-index in draft-fujisaki-dhc-addr-select-opt-00.txt is suggested to be one byte, which I'm not sure is sufficient. Also the label is a single byte which might be fine. Some implementations of 3484 seem to have long text strings as labels, but hopefully they could also cope with short numerical strings like "1" and "100". > > As I posted before, this draft describes the RFC3484 policy table > > distribution (please refer http://www.nttv6.net/dass). > > I've read this page, too. My current impression is that "I see some > point, but I'm not sure if it's enough for introducing a new DHCPv6 > option". > > Specifically, > > > Case1: IPv4 or IPv6 Prioritization > > I see this is a case where the automatic policy distribution may > help. But since the address selection by RFC3484 is much more > powerful than just selection between IPv4 and IPv6, I don't think this > can be a convincing usage if this is the only meaningful case. > > > Case2: ULA or Global Prioritization When using ULAs and globals together, I think you may want different rules depending on whether you have peerings with other sites using different ULA IDs or not. Stig > > Case3: Multicast Source Address Selection > > For these cases, using a non default policy table could resolve the > issue (and automatic policy distribution would help), but I personally > think this should be rather dealt with through a clarification for the > "default" selection rule, with the fact that site-local unicast > addresses were deprecated and ULAs are introduced. > > > Case4: Global and Closed Mixed Connectivity > > This may look a valid use case superficially, but people will actually > wonder why ISP2 needs (or can have) global (non ULA) addresses, or > even any IPv6 addresses, to begin with, if it's not connected to the > global Internet. And, for example, if the closed network uses ULAs > and we clarify the "default" address selection policy, we'll be just > happy with the clarified default policy (we may also need the new > '/54' allocation policy as well, though). Or, if ISP2 just uses > private IPv4 addresses, we'll just be happy even with the current > default rules. Unless the usage example answers to this natural > question, I'm afraid this will look artificial (and thus cannot be > convincing). > > 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 Wed Jul 27 08:37:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxl9t-0000SF-HF; Wed, 27 Jul 2005 08:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxl9r-0000Rm-F2 for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 08:37:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23094 for ; Wed, 27 Jul 2005 08:37:09 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxlf6-0003LI-Ff for ipv6@ietf.org; Wed, 27 Jul 2005 09:09:29 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j6RCafi25184; Wed, 27 Jul 2005 15:36:41 +0300 Date: Wed, 27 Jul 2005 15:36:41 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> <20050723.140110.115902850.fujisaki@syce.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-195097535-1122467801=:25080" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipv6@ietf.org, fujisaki@syce.net Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org 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-195097535-1122467801=:25080 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id j6RCafi25184 Content-Transfer-Encoding: quoted-printable On Wed, 27 Jul 2005, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8= wrote: >> Case2: ULA or Global Prioritization >> Case3: Multicast Source Address Selection > > For these cases, using a non default policy table could resolve the > issue (and automatic policy distribution would help), but I personally > think this should be rather dealt with through a clarification for the > "default" selection rule, with the fact that site-local unicast > addresses were deprecated and ULAs are introduced. This brings up another point which has been brought up in the past.=20 There is an agenda item for progressing the base IPv6 spec to full=20 standard. I suggest we move that discussion to happen prior to this=20 presentation, and augment the discussion to include revising RFC3484=20 (and moving it to Draft Standard). --=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-195097535-1122467801=:25080 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-195097535-1122467801=:25080-- From ipv6-bounces@ietf.org Wed Jul 27 10:27:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxmsY-0008K1-9s; Wed, 27 Jul 2005 10:27:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxmsT-0008I4-Uo; Wed, 27 Jul 2005 10:27:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02270; Wed, 27 Jul 2005 10:27:19 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxnNi-0006xa-Kz; Wed, 27 Jul 2005 10:59:41 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 472FA15218; Wed, 27 Jul 2005 23:27:09 +0900 (JST) Date: Wed, 27 Jul 2005 23:27:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Syam Madanapalli In-Reply-To: <10e14db2050727035827463def@mail.gmail.com> References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> <10e14db2050727035827463def@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: dhcwg@ietf.org, Iljitsch van Beijnum , IETF IPv6 Mailing List Subject: Re: [dhcwg] Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 27 Jul 2005 16:28:02 +0530, >>>>> Syam Madanapalli said: > The flags are just hints, the host can always ignore > them. If it is inappropriate to try to use DHCP when flags > are zero, let it be so. Similarly if the flag(s) is (are) set, > the host can always ignore. Yes, this is my understanding, too, and I think we don't have to revisit this agreement. However, at this stage of listing requirements, I'd rather be open to any possibilities, including those which could be regarded as a trigger. In fact, the next stage where we'll discuss how to implement those, we may reject some of the requirements if we cannot find any way of realizing them without breaking the base consensus. 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 Wed Jul 27 11:06:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnU3-0003c4-Mf; Wed, 27 Jul 2005 11:06:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnU1-0003bi-JX for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 11:06:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05508 for ; Wed, 27 Jul 2005 11:06:06 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxnzG-0008KY-0O for ipv6@ietf.org; Wed, 27 Jul 2005 11:38:29 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA05022; Wed, 27 Jul 2005 10:04:04 -0500 (CDT) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6RF44v03536; Wed, 27 Jul 2005 10:04:04 -0500 (CDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 27 Jul 2005 11:03:39 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2005 11:03:38 -0400 Message-ID: Thread-Topic: NSAP Address IPv6 option Thread-Index: AcWSkeB67N8LoQO2QGO4Hpk++rDm8gAKHu0g From: "Manfredi, Albert E" To: "Brian E Carpenter" X-OriginalArrivalTime: 27 Jul 2005 15:03:39.0446 (UTC) FILETIME=[5EF3A560:01C592BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Subject: RE: NSAP Address IPv6 option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Brian, if I have this right, you're talking about two possibilities here: 1. Release the NSAPA destination option code, and have IANA mark it as "reserved," or 2. Do nothing, which retains the NSAPA designation for that option code 0xC3. Is there any practical value to changing the designation from NSAPA to "reserved"? If one takes work and the other does not, I'm not sure why bother. In the future, can a request be made to the IANA to reassign that 0xC3 option code to some new use, citing RFC 4048 as a reason why this is okay to do? Bert =20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Wednesday, July 27, 2005 4:56 AM > To: Templin, Fred L > Cc: IPv6; Bob Hinden > Subject: Re: NSAP Address IPv6 option >=20 > I haven't seen any more discussion on this. >=20 > It makes perfect sense to post errata, and as document > editor I can do that, but we also need to send a request to > IANA, as Bob suggested, and that presumably needs WG > consensus to be declared, which is outside my scope. >=20 > Brian >=20 > Templin, Fred L wrote: > > Why not just post this as errata to RFC4048? > >=20 > > Fred=20 > >=20 > > -----Original Message----- > > From: Bob Hinden [mailto:bob.hinden@nokia.com]=20 > > Sent: Monday, July 11, 2005 10:18 AM > > To: Brian E Carpenter > > Cc: IPv6 > > Subject: Re: NSAP Address IPv6 option > >=20 > > Brian, > >=20 > > At 07:04 AM 07/11/2005, Brian E Carpenter wrote: > >=20 > >>RFC 1888 defined a destination option called "NSAP Address" > >>with option type code 11-0-00011 =3D 195 decimal, C3 hexadecimal. > >> > >>Unfortunately, the IANA Considerations in RFC 4048 > >>faild to discuss this option. It is still listed at > >>http://www.iana.org/assignments/ipv6-parameters > >> > >>My opinion is that it can be released; I'm aware of no usage. > >> > >>Any objections? Can the WG Chairs suggest a procedure to avoid > >>the overhead of another trivial RFC? > >=20 > >=20 > > The chairs could send an email to the IANA (with cc's to=20 > the IPv6 list > > and=20 > > IESG) with something to the effect that since RFC4048 made RFC1888=20 > > historic, the destination option defined by RFC1888 is no=20 > longer needed > > and=20 > > should be marked as Reserved. This was the intention of=20 > RFC4048, but > > was=20 > > omitted in error. > >=20 > > The only downside of this approach I can think of is that=20 > there wouldn't > > be=20 > > an RFC documenting the change. I am not sure this is a big deal in > > this case. > >=20 > > Other opinions and/or suggestions? > >=20 > > Bob > >=20 > >=20 > >=20 > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 >=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 Wed Jul 27 11:40:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxo0x-0005o4-NX; Wed, 27 Jul 2005 11:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxo0w-0005nw-4o; Wed, 27 Jul 2005 11:40:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08264; Wed, 27 Jul 2005 11:40:06 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxoW9-00015Z-Ri; Wed, 27 Jul 2005 12:12:29 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j6RFeJk0026523 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 27 Jul 2005 17:40:19 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> <10e14db2050727035827463def@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <3EF5FB91-BAC6-42C8-B8D2-E96FB9664567@muada.com> Content-Transfer-Encoding: quoted-printable From: Iljitsch van Beijnum Date: Wed, 27 Jul 2005 17:39:37 +0200 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_00,BODY_8BITS, ILJQX_TO_UTF8 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: [dhcwg] Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 27-jul-2005, at 16:27, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: >> The flags are just hints, the host can always ignore >> them. If it is inappropriate to try to use DHCP when flags >> are zero, let it be so. Similarly if the flag(s) is (are) set, >> the host can always ignore. > Yes, this is my understanding, too, and I think we don't have to > revisit this agreement. Are we having this discussion now, or later/somewhere else? If so, =20 when/where? If we're going to have the discussion, we need to bite the bullet and =20= arrive at some solid conclusions. Passing arguments back and forth =20 for a while and then leaving it up in the air doesn't help.= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 27 11:42:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxo2l-0006G1-PK; Wed, 27 Jul 2005 11:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxo2k-0006Fq-7j for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 11:42:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08545 for ; Wed, 27 Jul 2005 11:41:59 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxoY1-0001BC-06 for ipv6@ietf.org; Wed, 27 Jul 2005 12:14:22 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA29438; Wed, 27 Jul 2005 08:41:37 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6RFfkv27185; Wed, 27 Jul 2005 10:41: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.211); Wed, 27 Jul 2005 08:41:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Jul 2005 08:41:35 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4F5D@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: jumbo frame of GbE and IPv6 -- A proposal Thread-Index: AcWSmd1Up/MFhFFJRn+dQ1hXWOqwQgAJrdnQ From: "Templin, Fred L" To: "Perry Lorier" X-OriginalArrivalTime: 27 Jul 2005 15:41:36.0139 (UTC) FILETIME=[ABF76DB0:01C592C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 Mailing List Subject: RE: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > > And why not NS? >=20 > Because when A talks to B, you want A to do the MTU discovery=20 > and for B > to "learn" the MTU too, but you don't want both sending MTU=20 > probes, only > one of them needs to do so. Disagree - PMTU probing is a unidirectional endeavor since the path from A->B may have completely different characteristics than B->A. 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 Wed Jul 27 11:46:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxo6d-0007Ru-4M; Wed, 27 Jul 2005 11:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxo6b-0007RM-Fa; Wed, 27 Jul 2005 11:46:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08917; Wed, 27 Jul 2005 11:45:58 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxobn-0001LE-KO; Wed, 27 Jul 2005 12:18:21 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9EA5D1521A; Thu, 28 Jul 2005 00:45:52 +0900 (JST) Date: Thu, 28 Jul 2005 00:45:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Iljitsch van Beijnum In-Reply-To: <3EF5FB91-BAC6-42C8-B8D2-E96FB9664567@muada.com> References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> <10e14db2050727035827463def@mail.gmail.com> <3EF5FB91-BAC6-42C8-B8D2-E96FB9664567@muada.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: [dhcwg] Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 27 Jul 2005 17:39:37 +0200, >>>>> Iljitsch van Beijnum said: >>> The flags are just hints, the host can always ignore >>> them. If it is inappropriate to try to use DHCP when flags >>> are zero, let it be so. Similarly if the flag(s) is (are) set, >>> the host can always ignore. >> Yes, this is my understanding, too, and I think we don't have to >> revisit this agreement. > Are we having this discussion now, or later/somewhere else? If so, > when/where? My hope is soon (but not right now) and here. 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 Wed Jul 27 12:37:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxoul-0000j6-Lk; Wed, 27 Jul 2005 12:37:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxouk-0000iW-B2; Wed, 27 Jul 2005 12:37:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12719; Wed, 27 Jul 2005 12:37:47 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxpQ2-00036U-0w; Wed, 27 Jul 2005 13:10:10 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 24CFA15218; Thu, 28 Jul 2005 01:37:48 +0900 (JST) Date: Thu, 28 Jul 2005 01:37:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org, dhcwg@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Tue, 26 Jul 2005 23:22:49 +0900, >>>>> JINMEI Tatuya said: > While opinions on the details so varied, we seem to have agreed that > we need to fix the requirements for those flags (or something > similar/replacement in RA) first. With some minor updates after clarification discussions, here is the latest version of the requirement list: 1) Ability to indicate to a host "DHCP is not available on this link", with the expectation that the host won't send any DHCP messages 1') Some people also wanted to indicate a stronger message of "do not try to find it" for some networks in requirement 1. Possible scenarios include bandwidth-sensitive networks (such as 3G?) and the case where attacks of rogue DHCPv6 messages are concerned. 1'') Some people (one person?) also wanted the ability to indicate to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not available on this link" (This is probably a combination like M=0&&O=1 would currently indicate). [Note: requirement 1'' can also have two variations: with or without the intent of "do not try to find it". But since the "some people" seem to be the same group, there is probably no version of 1'' without the intent] 2) Ability for a host to get all desired and available DHCP configuration with a single DHCP message exchange - if a host wants HCB, it sends an HCB request (Solicit) and receives HCB and/or ICB replies - if a host wants ICB, it sends an ICB request (Information-request) and receives ICB replies 3) Ability to do DHCP without having to configure routers (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or ICB anyway) [Note: this requirement may contradict requirement 1'. We'll need to determine which one should be honored or whether there is an intermediate compromise.] Terminology: HCB: getting address (and possible other) configuration information by Solicit/Advertise/Request/Reply exchanges ICB: getting other configuration than addresses (excluding addresses) by Information-request/Reply exchanges I hope the above summary correctly covers major points we've seen. Now, at the risk of causing another cycle of opinion storm, the followings are related notes on each point from the past discussion. (I'm trying to be just an editor aside from my own opinion, but, of course, I cannot 100% escape from that) Requirement 2 seems least controversial. In my understanding, this is basically for removing redundant probe packets or hopeless timeouts for unavailable service. In particular, we wanted to avoid scenario where an HCB client continues sending Solicits even if there is no HCB server but an ICB-only server, and even if the client can somehow benefit from the "ICB part" excluding addresses. Such a case is most likely a result from temporary dead servers or configuration errors, but we seem to have agreed that we want to deal with such cases. Requirement 2 can be met through some extensions to RFC3315 and RFC3736. The obvious question is whether we can accept such extensions in terms of standardization and compatibility with existing implementations. In particular, some people expressed concern about requiring changes to ICB-only (RFC3736) server implementations. In general, however, my understanding is that people were positive about upgrading the DHCPv6 specifications, considering the specification/implementation maturity. Requirement 1 generally comes from some types of networks such as cellular networks where network bandwidth or buttery consumption of end stations is sensitive issues. I think people generally understood the point and agreed that the appropriate mechanism for implementing this is flag(s) in RAs. However, opinions on the details appeared to vary, causing lots of confusion. The major controversial points are probably summarized in the succeeding sub-requirements: - whether we need to prohibit the use of DHCPv6 more strongly and explicitly (e.g., with a 'MUST NOT'), which corresponds to Requirement 1'. I know there is a strong opinion for this requirement, but I'm not sure if that was a majority. On the other hand, if we adopt this requirement with the strongest wording such as 'MUST NOT', it will contradict with Requirement 3 (if we agree that it has some valid points). Additionally, as we briefly talked very recently, such strongest text would also break our general agreement that the RA flag(s) are just a trigger without containing mandatory requirements. We'll probably need to seek some middle ground by, e.g., wording compromise. I don't have a specific idea about how to do that right now, though. - whether we need to separate the 'ability' for HCB and ICB, which corresponds to Requirement 1''. If we need to separate the two types of ability, it would likely be implemented through the two flags currently defined in RA (i.e., the M/O flags). The main motivation of separating the two flags appear to be the ability to suppress HCB (however strictly) by default, expecting ICB is more common. On the other hand, we now know combinations of these flags turn out to be a confusing issue than we originally thought and can cause weird corner for implementors. So, some people rather wanted to unify those flags into a single bit, indicating whether DHCPv6 service is available (whether it's HCB or ICB), and solve HCB vs ICB issues through extensions to DHCPv6. I've seen lots of opinions from many people for either side, and their points are almost orthogonal. I'd not expect one side can fully convince the other through further discussion. In my understanding, however, people who preferred the single bit could also live with the two bits. Also, possible extensions to DHCPv6 may make the combinations issues easier to handle. So, possible compromise here is to keep the two flags, and to clarify (or perhaps mitigate) the combination issues with DHCPv6 extensions. (I don't have a specific idea about how that can be done at this moment though). Requirement 3 is basically a trivial requirement unless we use very strong prohibition (e.g., MUST NOT) for Requirement 1', and perhaps we don't have to do anything about this. As some people pointed out, users/implementations would always ignore specifications when they want to do so. A minor issue is how we should be explicit about the flexibility in a specification (or any document that comes from this discussion). Perhaps we need to clarify the possibility explicitly in order to avoid confusion, or perhaps we should not even mention that since this is trivial and 'not IETF's business'. I guess this is pretty minor, and we can postpone the decision until the other bigger issues are resolved. I hope this lengthy message can be a helpful and constructive source of the next step for this discussion. 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 Wed Jul 27 13:28:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxphU-0007XG-29; Wed, 27 Jul 2005 13:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxphR-0007Wj-TG; Wed, 27 Jul 2005 13:28:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15560; Wed, 27 Jul 2005 13:28:05 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxqCi-0004Y4-5t; Wed, 27 Jul 2005 14:00:30 -0400 Received: from [192.168.2.4] (unknown [66.93.162.100]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 3E71656898; Wed, 27 Jul 2005 10:27:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Date: Wed, 27 Jul 2005 10:27:46 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List , =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Subject: Re: [dhcwg] Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Jul 27, 2005, at 12:21 AM, Iljitsch van Beijnum wrote: >> Requirement 1 simply says "DHCP is not available"; it doesn't say "do >> not try to find it". >> > > I disagree. On some networks it's inappropriate to try to use DHCPv6. > > And if hosts are going to look for DHCPv6 servers regardless of the > value of the M/O bits, what's the point of this whole discussion?? It's the difference between policy and mechanism. We can say that when the M/O bits say there is no DHCPv6 service on the network, the client SHOULD NOT try to do DHCPv6. Or we can say that when the M/O bits say there is no DHCPv6 on the network, the client MUST NOT try to do DHCPv6. The latter statement leaves us with a lot less wiggle room, and is hard to justify in any but the most resource-constrained context. A client implemented for such a context benefits from following the SHOULD NOT, so there is probably no need for a MUST NOT. I should note that I don't actually care one way or another whether it's a SHOULD NOT or a MUST NOT, because I don't think we have enough operational experience to understand what the problems will be either way. So I suspect that whatever is said on this in the next draft of any document that comes out, it will not be the last word. On that basis, I think we should try our best to get it right, but not freak out about getting it right. :'} -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 27 17:29:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxtTD-0000E5-1z; Wed, 27 Jul 2005 17:29:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxtTA-0000Dz-R4 for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 17:29:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04447 for ; Wed, 27 Jul 2005 17:29:37 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx1.orcon.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxtyU-00040Y-Dc for ipv6@ietf.org; Wed, 27 Jul 2005 18:02:04 -0400 Received-SPF: none (dbmail-mx1.orcon.net.nz: domain of perry@coders.net does not designate permitted sender hosts) receiver=dbmail-mx1.orcon.net.nz; client-ip=60.234.141.149; envelope-from=; helo=elmer.coders.tla; Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx1.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j6RLUHjt017479; Thu, 28 Jul 2005 09:30:20 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1DxtSn-00025H-00; Thu, 28 Jul 2005 09:29:17 +1200 Message-ID: <42E7FCAD.5000103@coders.net> Date: Thu, 28 Jul 2005 09:29:17 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050724 X-Accept-Language: en-nz, en MIME-Version: 1.0 To: "Templin, Fred L" References: <39C363776A4E8C4A94691D2BD9D1C9A10D4F5D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4F5D@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/995/Thu Jul 28 08:13:50 2005 on dbmail-mx1.orcon.net.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Templin, Fred L wrote: >>>And why not NS? >> >>Because when A talks to B, you want A to do the MTU discovery >>and for B >>to "learn" the MTU too, but you don't want both sending MTU >>probes, only >>one of them needs to do so. > > > Disagree - PMTU probing is a unidirectional endeavor since the path > from A->B may have completely different characteristics than B->A. But this isn't on a path, it's on the same L2. L2 traditionally is a spanning tree, or broadcast media so the assumption seems to hold. While asymmetric paths are common on a L3 path, they are rare on L2. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jul 27 18:08:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxu4u-0003SY-Bz; Wed, 27 Jul 2005 18:08:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxu4s-0003SQ-RZ for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 18:08:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07031 for ; Wed, 27 Jul 2005 18:08:35 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxuaC-0004zR-Ur for ipv6@ietf.org; Wed, 27 Jul 2005 18:41:02 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA10836; Wed, 27 Jul 2005 15:08:10 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6RM8Ks15872; Wed, 27 Jul 2005 15:08:20 -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.211); Wed, 27 Jul 2005 15:08:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Jul 2005 15:08:17 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4F63@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: jumbo frame of GbE and IPv6 -- A proposal Thread-Index: AcWS8kRbrGd9TW6aShe0esGasw6wowAAwKQQ From: "Templin, Fred L" To: "Perry Lorier" X-OriginalArrivalTime: 27 Jul 2005 22:08:18.0495 (UTC) FILETIME=[B1A5FCF0:01C592F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 Mailing List Subject: RE: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > > Disagree - PMTU probing is a unidirectional endeavor since the path > > from A->B may have completely different characteristics than B->A. >=20 > But this isn't on a path, it's on the same L2. L2 traditionally is a > spanning tree, or broadcast media so the assumption seems to hold. When a tunnel is used, there may be many L2 segments (connected by L2 switches) with diverse MTUs separating the tunnel endpoints in what otherwise appears as a single-hop to L3. And, the set of L2 segments will often be different in the forward and reverse directions. I asked this earlier, but where are we at in the decision process for native IPv6 vs tunneled? 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 Wed Jul 27 18:25:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxuKm-00080z-Pv; Wed, 27 Jul 2005 18:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxuKl-00080Q-5g for ipv6@megatron.ietf.org; Wed, 27 Jul 2005 18:25:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09819 for ; Wed, 27 Jul 2005 18:24:59 -0400 (EDT) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxuq5-0005Lh-Em for ipv6@ietf.org; Wed, 27 Jul 2005 18:57:26 -0400 Received: from dax (ip178.post-vineyard.dfw.ygnition.net [66.135.181.178]) by ns2.sea (8.13.4/8.12.5) with SMTP id j6RMOSF7006052; Wed, 27 Jul 2005 15:24:39 -0700 Message-ID: <025e01c592f9$fa918540$6701a8c0@dax> From: "Stephen Sprunk" To: "Perry Lorier" , "Templin, Fred L" References: <39C363776A4E8C4A94691D2BD9D1C9A10D4F5D@XCH-NW-7V2.nw.nos.boeing.com> <42E7FCAD.5000103@coders.net> Date: Wed, 27 Jul 2005 17:22:11 -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.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thus spake "Perry Lorier" > Templin, Fred L wrote: >> Disagree - PMTU probing is a unidirectional endeavor since the path >> from A->B may have completely different characteristics than B->A. > > But this isn't on a path, it's on the same L2. L2 traditionally is a > spanning tree, or broadcast media so the assumption seems to hold. > > While asymmetric paths are common on a L3 path, they are rare on L2. Spanning trees are most common at L2, but there are certainly media where we need to probe in both directions, particularly rings and tunnels. Might as well probe for all media since (a) it makes things clearer, and (b) an arbitrary 802.3 host has no way to know if its packets are being bridged to or tunneled over non-802.3 networks. 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 Thu Jul 28 01:35:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy12t-0006sz-TC; Thu, 28 Jul 2005 01:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy12q-0006rv-PB; Thu, 28 Jul 2005 01:35:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05363; Thu, 28 Jul 2005 01:34:59 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy1YE-0007rG-E9; Thu, 28 Jul 2005 02:07:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j6S5Yj812681; Thu, 28 Jul 2005 08:34:45 +0300 Date: Thu, 28 Jul 2005 08:34:44 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-393949458-1122528884=:12292" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org 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-393949458-1122528884=:12292 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id j6S5Yj812681 Content-Transfer-Encoding: quoted-printable On Thu, 28 Jul 2005, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8= wrote: > 1') Some people also wanted to indicate a stronger message of "do > not try to find it" for some networks in requirement 1. > Possible scenarios include bandwidth-sensitive networks (such > as 3G?) and the case where attacks of rogue DHCPv6 messages are > concerned. [,,,] > 3) Ability to do DHCP without having to configure routers > (e.g., by ignoring RA with M=3D0 and/or O=3D0 and invoking HCB and/or > ICB anyway) > [Note: this requirement may contradict requirement 1'. We'll need > to determine which one should be honored or whether there is an > intermediate compromise.] [...] > Requirement 1 generally comes from some types of networks such as > cellular networks where network bandwidth or buttery consumption of > end stations is sensitive issues. I think people generally understood > the point and agreed that the appropriate mechanism for implementing > this is flag(s) in RAs. > > However, opinions on the details appeared to vary, causing lots of > confusion. The major controversial points are probably summarized in > the succeeding sub-requirements: > > - whether we need to prohibit the use of DHCPv6 more strongly and > explicitly (e.g., with a 'MUST NOT'), which corresponds to > Requirement 1'. Let me try to offer a point here (and sorry if this is too early) why=20 I don't think a MUST NOT is not a requirement. Specifically, I'm not sure if there are valid scenarios where these 3G=20 or other devices, which must conserve bandwidth, would implement=20 requirement 3, specifically in the interfaces associated with=20 conserved bandwidth? (This question could be asked differently: "Are=20 there networks where the network must tell that the hosts must=20 conserve bandwidth, otherwise the hosts don't know it?".) It seems to me that those 3G vendors probably won't implement=20 requirement 3 (unless explicitly configured otherwise) at least on=20 their 3G interface, and then the whole problem goes away, because even=20 if the hosts implemented DHCPv6, they wouldn't use it on the interface=20 unless the network gives a sign they should. On the other hand, if a=20 vendor does implement it, and the user has to pay for the wasted=20 bandwidth, I guess the user is going to complain about it and it'll=20 get fixed. I'm not sure if there are some cornercases wrt. the security argument=20 where this can't be as easily solved. --=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-393949458-1122528884=:12292 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-393949458-1122528884=:12292-- From ipv6-bounces@ietf.org Thu Jul 28 01:37:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy159-0007AC-64; Thu, 28 Jul 2005 01:37:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy156-0007A7-Rk for ipv6@megatron.ietf.org; Thu, 28 Jul 2005 01:37:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05507 for ; Thu, 28 Jul 2005 01:37:19 -0400 (EDT) Received: from smta08.mail.ozemail.net ([203.103.165.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy1aU-0007ue-3d for ipv6@ietf.org; Thu, 28 Jul 2005 02:09:48 -0400 Received: from ubu.nosense.org ([210.84.225.248]) by smta08.mail.ozemail.net with ESMTP id <20050728053655.PUHX4747.smta08.mail.ozemail.net@ubu.nosense.org>; Thu, 28 Jul 2005 05:36:55 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id B10BC62AAE; Thu, 28 Jul 2005 15:06:54 +0930 (CST) Date: Thu, 28 Jul 2005 15:06:54 +0930 From: Mark Smith To: Iljitsch van Beijnum Message-Id: <20050728150654.32354fae.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <8FA56653-D119-47C2-8434-BE0D32C8182B@muada.com> References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> <42E25E62.2010805@coders.net> <17E800F8-AAFF-4B67-8CF9-42CB69038694@muada.com> <42E394B2.5020409@coders.net> <42E622A7.8040206@coders.net> <8FA56653-D119-47C2-8434-BE0D32C8182B@muada.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; 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.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, perry@coders.net Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Iljitsch, Perry, I'll admit I haven't been fully following your thread of discussion, I've been a bit busy on some other things (another reason why I like the simple solution - less thinking :-) ) Something to keep in mind for your solution. TCP announces the maximum segment size it can receive in the SYN or SYN/ACK segments, and I'm pretty sure these days that is derived directly from the (current) MTU value of the interface it is going to use at the time of the 3-way handshake. I'm pretty sure that irrespective of if PMTUD (or another local link method) discovers a larger possible PMTU value at a later time during the TCP connection, existing TCP connections will not be able to "burst" up to it. Assuming that you're not planning to modify TCP as well, this means that the knowledge of the "best" possible MTU that TCP can use must be known at the time of the initial 3-way handshake. This limitation possibly applies to other unicast or semi-unicast transport layer protocols too, such as SCTP. Thinking about these solutions another way, all they're really attempting to do is to take the TCP-specific MSS mechanism, generalise it so it can be used for all transport layer unicast connections, and moving the mechanism to the network layer. 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 Jul 28 02:30:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy1uS-0005Ou-Nu; Thu, 28 Jul 2005 02:30:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy1uP-0005NL-VE; Thu, 28 Jul 2005 02:30:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29133; Thu, 28 Jul 2005 02:30:20 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy2Pn-0000jD-Is; Thu, 28 Jul 2005 03:02:49 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:616e:ba46:f0c5:48a]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B100515218; Thu, 28 Jul 2005 15:30:12 +0900 (JST) Date: Thu, 28 Jul 2005 15:30:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Thu, 28 Jul 2005 08:34:44 +0300 (EEST), >>>>> Pekka Savola said: >> 1') Some people also wanted to indicate a stronger message of "do >> not try to find it" for some networks in requirement 1. >> Possible scenarios include bandwidth-sensitive networks (such >> as 3G?) and the case where attacks of rogue DHCPv6 messages are >> concerned. > [,,,] >> 3) Ability to do DHCP without having to configure routers >> (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or >> ICB anyway) >> [Note: this requirement may contradict requirement 1'. We'll need >> to determine which one should be honored or whether there is an >> intermediate compromise.] > [...] >> Requirement 1 generally comes from some types of networks such as >> cellular networks where network bandwidth or buttery consumption of >> end stations is sensitive issues. I think people generally understood >> the point and agreed that the appropriate mechanism for implementing >> this is flag(s) in RAs. >> >> However, opinions on the details appeared to vary, causing lots of >> confusion. The major controversial points are probably summarized in >> the succeeding sub-requirements: >> >> - whether we need to prohibit the use of DHCPv6 more strongly and >> explicitly (e.g., with a 'MUST NOT'), which corresponds to >> Requirement 1'. > Let me try to offer a point here (and sorry if this is too early) If my analysis captured the past discussion correctly, I think we can now start the next phase, including which ones are valid requirements. > why > I don't think a MUST NOT is not a requirement. Difficult to parse...so you mean you think 'MUST NOT' is a requirement:-) > Specifically, I'm not sure if there are valid scenarios where these 3G > or other devices, which must conserve bandwidth, would implement > requirement 3, specifically in the interfaces associated with > conserved bandwidth? (This question could be asked differently: "Are > there networks where the network must tell that the hosts must > conserve bandwidth, otherwise the hosts don't know it?".) > It seems to me that those 3G vendors probably won't implement > requirement 3 (unless explicitly configured otherwise) at least on > their 3G interface, and then the whole problem goes away, because even > if the hosts implemented DHCPv6, they wouldn't use it on the interface > unless the network gives a sign they should. On the other hand, if a > vendor does implement it, and the user has to pay for the wasted > bandwidth, I guess the user is going to complain about it and it'll > get fixed. I generally agree with this view. This issue here is, I think, how we should reflect that in the document/specification we are going to produce (if any): - simply saying 'MUST NOT invoke DHCPv6 if the signal (whatever it is) is off' is overkilling, unless we also agree this rule should be applied not only to some special type of network like 3G but also to any type of networks. - then should we say something like this? "...MUST NOT invoke DHCPv6 if the signal is off for such networks as 3G, where bandwidth is scarce commodity and/or consuming client's buttery is unacceptable." Can we sufficiently and correctly specify 'such networks' to which the 'MUST NOT" is applied? - personally, I'd make this as a side-note for some specific types of networks, e.g., "for some types of networks, clients may not want to start DHCPv6 unless the availablity of the service is explicitly signaled via RA. An examples of such networks is 3G, where bandwidth is scarce commodity and/or consuming client's buttery is unacceptable." > I'm not sure if there are some cornercases wrt. the security argument > where this can't be as easily solved. ??? I don't understand how this relates to the 'MUST NOT' discussion (or even what this sentence really means)...could you elaborate? 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 Jul 28 03:09:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2W8-0008AG-Rh; Thu, 28 Jul 2005 03:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2W5-00089j-CY; Thu, 28 Jul 2005 03:09:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01383; Thu, 28 Jul 2005 03:09:14 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy31Q-0001ix-Sw; Thu, 28 Jul 2005 03:41:44 -0400 Received: from ep_mmp2 (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 <0IKB00CD8T3J9E@mailout3.samsung.com>; Thu, 28 Jul 2005 16:06:55 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IKB00JSPT3I3R@mmp2.samsung.com>; Thu, 28 Jul 2005 16:06:55 +0900 (KST) Date: Thu, 28 Jul 2005 16:04:06 +0900 From: Soohong Daniel Park In-reply-to: To: =?ks_c_5601-1987?B?J0pJTk1FSSBUYXR1eWEgLyA/lr6SQo3GJw==?= , ipv6@ietf.org, dhcwg@ietf.org Message-id: <001201c59342$8b400380$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7BIT Cc: Subject: RE: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >3) Ability to do DHCP without having to configure routers > (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or > ICB anyway) Let me clarify here, are you saying DHCP client invokes its HCB and/or ICB regardless of RA (or in case where RA is not available) ? Regards, --------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Lab., SAMSUNG Electronics. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 28 03:15:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2c0-0000qU-7T; Thu, 28 Jul 2005 03:15:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2by-0000qL-Gt for ipv6@megatron.ietf.org; Thu, 28 Jul 2005 03:15:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01681 for ; Thu, 28 Jul 2005 03:15:20 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy37O-0001tC-8Y for ipv6@ietf.org; Thu, 28 Jul 2005 03:47:50 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j6S7F8mp119926 for ; Thu, 28 Jul 2005 07:15:08 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6S7F81m193830 for ; Thu, 28 Jul 2005 09:15:08 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j6S7F7XA022466 for ; Thu, 28 Jul 2005 09:15:07 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j6S7F7A1022451; Thu, 28 Jul 2005 09:15:07 +0200 Received: from zurich.ibm.com (sig-9-146-216-63.de.ibm.com [9.146.216.63]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA65452; Thu, 28 Jul 2005 09:15:06 +0200 Message-ID: <42E885F5.6030304@zurich.ibm.com> Date: Thu, 28 Jul 2005 09:15:01 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Manfredi, Albert E" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: Re: NSAP Address IPv6 option (request to WG chairs) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Bert, Over in another part of the universe, there's been quite a discussion about the prudence required in the management of limited namespaces, including IP options. As a result, I don't want to leave what is basically garbage in the IANA registry. So here is where I am at now, after the discussion here: 1. I will, right now, send an erratum note to the RFC Editor to correct the omission in RFC 4048. 2. I request the WG Chairs to make a consensus call on this proposal: The WG agrees to request the IANA to mark IPv6 option type code 11-0-00011 = 195 decimal, C3 hexadecimal as available for assignment. Rationale: it's clear that this part of RFC 1888 was never implemented by anybody, and we should not tie up a namespace resource as a result. Brian Manfredi, Albert E wrote: > Brian, if I have this right, you're talking about two possibilities > here: > > 1. Release the NSAPA destination option code, and have IANA mark it as > "reserved," or > > 2. Do nothing, which retains the NSAPA designation for that option code > 0xC3. > > Is there any practical value to changing the designation from NSAPA to > "reserved"? If one takes work and the other does not, I'm not sure why > bother. > > In the future, can a request be made to the IANA to reassign that 0xC3 > option code to some new use, citing RFC 4048 as a reason why this is > okay to do? > > Bert > > > >>-----Original Message----- >>From: Brian E Carpenter [mailto:brc@zurich.ibm.com] >>Sent: Wednesday, July 27, 2005 4:56 AM >>To: Templin, Fred L >>Cc: IPv6; Bob Hinden >>Subject: Re: NSAP Address IPv6 option >> >>I haven't seen any more discussion on this. >> >>It makes perfect sense to post errata, and as document >>editor I can do that, but we also need to send a request to >>IANA, as Bob suggested, and that presumably needs WG >>consensus to be declared, which is outside my scope. >> >> Brian >> >>Templin, Fred L wrote: >> >>>Why not just post this as errata to RFC4048? >>> >>>Fred >>> >>>-----Original Message----- >>>From: Bob Hinden [mailto:bob.hinden@nokia.com] >>>Sent: Monday, July 11, 2005 10:18 AM >>>To: Brian E Carpenter >>>Cc: IPv6 >>>Subject: Re: NSAP Address IPv6 option >>> >>>Brian, >>> >>>At 07:04 AM 07/11/2005, Brian E Carpenter wrote: >>> >>> >>>>RFC 1888 defined a destination option called "NSAP Address" >>>>with option type code 11-0-00011 = 195 decimal, C3 hexadecimal. >>>> >>>>Unfortunately, the IANA Considerations in RFC 4048 >>>>faild to discuss this option. It is still listed at >>>>http://www.iana.org/assignments/ipv6-parameters >>>> >>>>My opinion is that it can be released; I'm aware of no usage. >>>> >>>>Any objections? Can the WG Chairs suggest a procedure to avoid >>>>the overhead of another trivial RFC? >>> >>> >>>The chairs could send an email to the IANA (with cc's to >> >>the IPv6 list >> >>>and >>>IESG) with something to the effect that since RFC4048 made RFC1888 >>>historic, the destination option defined by RFC1888 is no >> >>longer needed >> >>>and >>>should be marked as Reserved. This was the intention of >> >>RFC4048, but >> >>>was >>>omitted in error. >>> >>>The only downside of this approach I can think of is that >> >>there wouldn't >> >>>be >>>an RFC documenting the change. I am not sure this is a big deal in >>>this case. >>> >>>Other opinions and/or suggestions? >>> >>>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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 28 03:45:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy34d-0001Qo-PQ; Thu, 28 Jul 2005 03:44:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy34b-0001QG-AT; Thu, 28 Jul 2005 03:44:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03158; Thu, 28 Jul 2005 03:44:55 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy3a0-0002uT-5s; Thu, 28 Jul 2005 04:17:25 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IKB000QKUUHGS@mailout2.samsung.com>; Thu, 28 Jul 2005 16:44:41 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IKB00GEZUUH56@mmp1.samsung.com>; Thu, 28 Jul 2005 16:44:41 +0900 (KST) Date: Thu, 28 Jul 2005 16:41:52 +0900 From: Soohong Daniel Park In-reply-to: To: "'Pekka Savola'" , =?ks_c_5601-1987?B?J0pJTk1FSSBUYXR1eWEgLyA/lr6SQo3GJw==?= Message-id: <001501c59347$d2163900$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >Let me try to offer a point here (and sorry if this is too early) why >I don't think a MUST NOT is not a requirement. >[omitted] On the other hand, if a >vendor does implement it, and the user has to pay for the wasted >bandwidth, I guess the user is going to complain about it and it'll >get fixed. I see and that is an important point to vendors, however a host already configures its address can invoke at least ICB to get its information regardless of RA indication. Regards, --------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Lab., SAMSUNG Electronics. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 28 03:48:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy37m-0001nD-4i; Thu, 28 Jul 2005 03:48:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy37k-0001mg-AT; Thu, 28 Jul 2005 03:48:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03350; Thu, 28 Jul 2005 03:48:10 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy3d8-0002zO-Gs; Thu, 28 Jul 2005 04:20:40 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:4819:7972:7e9e:4f2a:e055]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 31D9D15218; Thu, 28 Jul 2005 16:48:01 +0900 (JST) Date: Thu, 28 Jul 2005 16:48:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Soohong Daniel Park In-Reply-To: <001201c59342$8b400380$6cc6dba8@daniel> References: <001201c59342$8b400380$6cc6dba8@daniel> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Thu, 28 Jul 2005 16:04:06 +0900, >>>>> Soohong Daniel Park said: >> 3) Ability to do DHCP without having to configure routers >> (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or >> ICB anyway) > Let me clarify here, are you saying DHCP client invokes > its HCB and/or ICB regardless of RA (or in case where RA > is not available) ? In the example, yes. The requirement itself might be met by other solutions, but I could not find any alternatives in the past discussions. 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 Jul 28 04:29:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy3m0-0006ZT-OR; Thu, 28 Jul 2005 04:29:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy3lx-0006ZO-NJ for ipv6@megatron.ietf.org; Thu, 28 Jul 2005 04:29:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05786 for ; Thu, 28 Jul 2005 04:29:43 -0400 (EDT) Received: from p127202.doubleroute.jp ([219.119.127.202] helo=s51.ath.cx) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy4HL-0004Hd-2G for ipv6@ietf.org; Thu, 28 Jul 2005 05:02:14 -0400 Received: from [192.47.163.103] (dhcp-3-103.nttv6.com [192.47.163.103]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by s51.ath.cx (Postfix) with ESMTP id 5536270C31; Thu, 28 Jul 2005 17:29:12 +0900 (JST) In-Reply-To: References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> <20050723.140110.115902850.fujisaki@syce.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=ISO-2022-JP Message-Id: <23581AF9-3CBA-47B5-AE80-D9CEF16B87D7@arifumi.net> Content-Transfer-Encoding: 7bit From: Arifumi Matsumoto Date: Thu, 28 Jul 2005 17:28:57 +0900 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.6 (++) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, fujisaki@syce.net Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I'm co-author of this draft and web-page. Thank you for comments, Jinmei-san ,Stig. > I've read the latest draft, but I'm afraid the document itself doesn't > help assess whether the ipv6 wg can support that or not, since it > mainly concentrates on the DHCPv6 specific issues. > > I believe what should be discussed in this group is the intended > scenarios (the "Practical Usage" section) described in this URL: At first, we planned to publish another Internet-Draft that describes practical usages of this DHCP option. But we found that these usages are almost the same as those written in Section 10 of RFC 3484. So, instead of writing another draft, I summarized some issues related to our proposal in this web page, which includes implementation status of address selection policy table, abstract of our proposing DHCP option and usages of it. To show all of you the related information at a glance. This is an excuse for not writing a Internet-Draft. ;) > >> As I posted before, this draft describes the RFC3484 policy table >> distribution (please refer http://www.nttv6.net/dass). >> > > I've read this page, too. My current impression is that "I see some > point, but I'm not sure if it's enough for introducing a new DHCPv6 > option". > > Specifically, > > >> Case1: IPv4 or IPv6 Prioritization >> > > I see this is a case where the automatic policy distribution may > help. But since the address selection by RFC3484 is much more > powerful than just selection between IPv4 and IPv6, I don't think this > can be a convincing usage if this is the only meaningful case. > > >> Case2: ULA or Global Prioritization >> Case3: Multicast Source Address Selection >> > > For these cases, using a non default policy table could resolve the > issue (and automatic policy distribution would help), but I personally > think this should be rather dealt with through a clarification for the > "default" selection rule, with the fact that site-local unicast > addresses were deprecated and ULAs are introduced. As you mention it, if ULA's address scope is defined like Scope(link-local) < Scope(ULA) < Scope(Global), the case 2 problem will be solved. As Stig has pointed out, however, defining an appropriate scope for ULA doesn't solve all the problems related to ULA site, which I described below. > > >> Case4: Global and Closed Mixed Connectivity >> > > This may look a valid use case superficially, but people will actually > wonder why ISP2 needs (or can have) global (non ULA) addresses, or > even any IPv6 addresses, to begin with, if it's not connected to the > global Internet. And, for example, if the closed network uses ULAs > and we clarify the "default" address selection policy, we'll be just > happy with the clarified default policy (we may also need the new > '/54' allocation policy as well, though). Or, if ISP2 just uses > private IPv4 addresses, we'll just be happy even with the current > default rules. Unless the usage example answers to this natural > question, I'm afraid this will look artificial (and thus cannot be > convincing). As for this point, we've had a related dialogue just before the previous IETF meeting on dhcwg ML, which I paste below. A VPN connectivity and a native IPv6 connectivity environment can be an answer to the first question. That is, a site has a native IPv6 connectiviy and also has a VPN connection, over the native IPv6 line, to another site that doesn't provide transit connectivity to a VPN-connected site. In this case, the same problem occurs as the case 4. In addition to this, what we believe is that ASP services like video streaming, ip phone, security service and home appliance maintenance will be getting into home networks and this trend has already started to happen. Even if each of these ASPs uses ULA, address selection problem occurs once one of them has a peering with another site or once one of them acquires another ULA block. thanks. Begin forwarded message: > From: (Tomohiro -INSTALLER- Fujisaki/$BF#:j(B $BCR9((B) > Date: 2005$BG/(B3$B7n(B10$BF|(B 13:57:42:JST > To: jinmei@isl.rdc.toshiba.co.jp > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] comments on draft-hirotaka-dhc-source-address-selection-opt-01.txt > X-Mailer: Mew version 4.2 on XEmacs 21.4.15 (Security Through Obscurity) > > > > Junmei-san, > > Thank you for reading our draft in detail. > > | Substantial comments (or questions) > | > | 1. at least from this document, it's not clear whether we really need > | this kind of generic DHCPv6 option. In particular, the assumption > | in section 6 that ISP1 doesn't have global connectivity while ISP2 > | does seems very artificial. I cannot understand why we are > | suddenly led to this example. > > We believe that the closed network example is not artificial. There > will be some cases that users want to use multiple connections > simultaneously, such as global connectivity and VPN, and global > connectivity and some kind of ASP services (Video streaming, IP Phone > and maintenance of home appliances). Actually, some implementation > of IP phone already uses closed network model. > > | If this option is useful for a general multihome case, the draft > | should first discuss that case (rather than the odd-looking > | unbalanced example). But it does not seem to be the case to me (or > | at least it's not clear to me). > | > | What happens if both ISP1 and ISP2 have global IPv6 connectivity? > | Can this option help something in this case? > > CPE router can inform nodes which prefix should be used to a > destination prefix (in this situation, CPE router will inform > the nodes which uplink is selected as default). > > | On the other hand, assume neither ISP1 nor ISP2 has global IPv6 > | connectivity. Then isn't it enough to let the "longest-matching" > | rule of RFC3484 do the job for avoiding the trap of ingress > | filtering? > > Basically yes. > > However, end user network knows assigned prefix information only > and it has no information abut other prefixes that upstream ISPs > may have. This may be covered if routing information is available, > but in this case, other problem will occur (I'll describe below). > > | I also have a question from yet another point of view. In the > | "unbalanced" example of Section 6, the essential information for > | the "user router" seems the fact packets to A::/32 should be sent > | to ISP1 and others (including ::/0) to ISP2. This is, in essence, > | just routing information. Since we already need some kind of > | routing information in the typical PD usage, I don't see the need > | for the redundant information baring the new DHCPv6 option. > > There are some cases that address selection policy cannot be created > from the routing information. > > For example, > - a router that advertise routing information and a DHCP-PD server is > the different node. > > - a DHCP-PD server wants to assign multiple prefixes that have > different selection policy. > > In these cases, it is generally impossible to make relationships > between routing information and assigned prefix. > > > | BTW: in the case of the PD usage, the "assigned" prefix (e.g., > | A::/48) should be provided in the PD framework, so this information > | in the SASP option seems redundant. > > If the DHCP-PD router assigns only one prefix, it may be surely > redundant to have the prefix value in SASP option. But it is > necessary to keep the relation of assigned prefix and SASP policy, > when it delivers multiple prefixes and multiple policies. > > | I see we may need some new mechanism between the user router and > | end nodes in order to relate the routing information (e.g., the > | default route is the path to ISP2) to source address selection > | rules, in order to avoid the ingress filtering trap. But, in this > | case, I think we only need a single mechanism, whether it's DHCPv6 > | or RA. Remember that even an end host that configures addresses by > | stateless address autoconfiguration may still need DHCPv6 for > | getting (recursive) DNS server addresses. Similarly, even an end > | host that configures addresses by DHCPv6 will still need RAs to get > | on-link prefixes. So, a single mechanism would be enough for > | providing source address selection rules, whether it's RA or > | DHCPv6, and whether receiving node uses RA or DHCPv6 for address > | configuration. > > Well, I think I have to look into more about this issue, whether DHCP > is always vital for every node or not. > > | BTW: the source address selection problem with ingress filtering is > | exactly what one of general multihoming issues. So, one may ask > | for discussing this in the context of (e.g.) multi6 wg. We'll at > | least need to be asked why we cannot use solutions being considered > | in multi6. > > Surely, ingress filtering issue in multiple global network connectivity > environment is multi6 matter. Our proposal can solve this issue as I > stated above, and I believe that our proposal can go well with the > coming multi6(shim6) new proposal for the hints of source address selection. > > Actually, we made a presentation at multi6 meeting in DC, and multi6 > chairs advised us multi6 does not target the closed network case. > > > | Semi-substantial comments > | > | 2. the scenario described in this draft seems to assume (perhaps > | implicitly) that the user router can get all the prefix information > | (from ISP1 and ISP2) at once. However, the PD procedures with the > | ISPs should in general be asynchronous events. So, the user router > | should somehow deal with the asynchronous information for providing > | consistent rules with end nodes. It's not very clear from the > | current draft on how the user router behaves wrt this concern. > | (Perhaps this is not a serious issue...I'm just not sure about this > | from the current text) > > This asynchronous behavior doesn't lead to such a serious trouble, > I agree that I have to mention about it too. > > | 3. In section 6, the draft says: > | > | o End nodes set up their IPv6 addresses by using a stateful DHCPv6 > | function or receiving router advertisement message. They also > | request the SASP option by transmitting Information-Request > | messages to the router. > | > | But if the end node uses DHCPv6 for address set-up, it should also > | be able to get the SASP option in this procedure; I don't see why > | the node needs to transmit Information-Request in this case. (But > | see also the more fundamental question above). > > Absolutely. I'll correct it soon. > > | 4. Also in Section 6, > | > | o When the requesting client detects a change in a delegated address > | or address prefix, it requests the Source Address Selection Policy > | option again. > | > | This statement is not very clear to me. What is the "requesting > | client" in this context? Is it the user router, a end node, or > | both? (Perhaps the definition in Section 3 is not very clear in the > | first place) Also, how does it "request" the option again? > > I fully agree that this sentence is surely ambiguous. > > What I wanted to say is: > > - a prefix and a source address selection policy is strongly bound. > - when a prefix is invalidated, the corresponding source address > selection policy also has to be invalidated. > > We'll rewrite this part. > > | 5. In section 7, > | > | A malicious DHCPv6 client may be able to mount a denial-of-service > | attack by sending repeated requests for the Source Address Selection > | Policy option, thus exhausting the DHCP server's resources. > | > | I'm not really sure about the point of this statement. What kind of > | "server's resources" are concerned here? Since the SASP is quite > | stateless, shouldn't the "malicious" client consume further > | "resources" such as address/prefix pools? Or, does this sentence > | considers the processing load at the sever side? But if so, > | > | To guard against attacks, both DCHP clients and servers SHOULD use > | DHCP authentication, as described in section 21 of RFC 3315, > | "Authentication of DHCP messages." > | > | I don't think this is very accurate. A malicious client can still > | bother the server, consuming the server's resource of processing load, > | by sending repeated requests with bogus authentication information. > > We will also rewrite security consideration section. > > | Editorial comments > | > | 6. In section 1, second paragraph > | s/packet- forwarding/packet-forwarding/ > | > | 7. there's a mixture of "usable" and "useable" in the second bullet of > | Section 6. This should be consistent. > | > | 8. In section 7, last paragraph > | s/"Authentication of DHCP messages."/"Authentication of DHCP messages."/ > | (there's a redundant white space) > > Thank you very much. > > Yours sincerely, > -- > Tomohiro Fujisaki > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories TEL: +81-422-59-3334 / FAX: +81-422-59-5652 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 28 06:19:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5UT-00059C-6Y; Thu, 28 Jul 2005 06:19:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5UR-000592-Su; Thu, 28 Jul 2005 06:19:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13216; Thu, 28 Jul 2005 06:19:42 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy5zq-0007we-4E; Thu, 28 Jul 2005 06:52:15 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j6SAJUqA019178; Thu, 28 Jul 2005 11:19:30 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA07457; Thu, 28 Jul 2005 11:19:06 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j6SAJ6w32327; Thu, 28 Jul 2005 11:19:06 +0100 Date: Thu, 28 Jul 2005 11:19:06 +0100 From: Tim Chown To: dhcwg@ietf.org, IETF IPv6 Mailing List Message-ID: <20050728101901.GA32116@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org, IETF IPv6 Mailing List References: <42E6E058.5040107@eng.monash.edu.au> <84D72376-5C0C-4DE6-9E9F-E21C546D7E1A@muada.com> <10e14db2050727035827463def@mail.gmail.com> <3EF5FB91-BAC6-42C8-B8D2-E96FB9664567@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF5FB91-BAC6-42C8-B8D2-E96FB9664567@muada.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: Re: [dhcwg] Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, Jul 27, 2005 at 05:39:37PM +0200, Iljitsch van Beijnum wrote: > On 27-jul-2005, at 16:27, JINMEI Tatuya / ???????????? wrote: > > >>The flags are just hints, the host can always ignore > >>them. If it is inappropriate to try to use DHCP when flags > >>are zero, let it be so. Similarly if the flag(s) is (are) set, > >>the host can always ignore. > > >Yes, this is my understanding, too, and I think we don't have to > >revisit this agreement. > > Are we having this discussion now, or later/somewhere else? If so, > when/where? > > If we're going to have the discussion, we need to bite the bullet and > arrive at some solid conclusions. Passing arguments back and forth > for a while and then leaving it up in the air doesn't help. There is a 15 min slot in the IPv6 WG agenda for Tuesday, and then a small slot in DHC on Thursday where the result (assuming we get one) of Tuesday can be discussed in the DHC context. -- Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jul 28 07:19:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy6Qg-0006RI-Dg; Thu, 28 Jul 2005 07:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy6Qe-0006RD-Lt for ipv6@megatron.ietf.org; Thu, 28 Jul 2005 07:19:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16848 for ; Thu, 28 Jul 2005 07:19:53 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy6w5-0001GC-R6 for ipv6@ietf.org; Thu, 28 Jul 2005 07:52:27 -0400 Received: from ([128.244.96.158]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.2535763; Thu, 28 Jul 2005 07:19:19 -0400 In-Reply-To: <42E885F5.6030304@zurich.ibm.com> References: <42E885F5.6030304@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: Brian Haberman Date: Thu, 28 Jul 2005 07:19:18 -0400 To: Brian E Carpenter X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: IPv6 Subject: Re: NSAP Address IPv6 option (request to WG chairs) X-BeenThere: ipv6@ietf.org 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="===============0201605982==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0201605982== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-360954650; protocol="application/pkcs7-signature" --Apple-Mail-1-360954650 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jul 28, 2005, at 3:15, Brian E Carpenter wrote: > Bert, > > Over in another part of the universe, there's been quite a > discussion about the prudence required in the management > of limited namespaces, including IP options. As a result, I > don't want to leave what is basically garbage in the IANA > registry. So here is where I am at now, after the > discussion here: > > 1. I will, right now, send an erratum note to the RFC Editor > to correct the omission in RFC 4048. > > 2. I request the WG Chairs to make a consensus call on this > proposal: > > The WG agrees to request the IANA to mark IPv6 > option type code 11-0-00011 = 195 decimal, C3 hexadecimal > as available for assignment. Since no one has objected to this, the chairs will proceed with drafting an e-mail to IANA asking them to free this codepoint. Regards, Brian --Apple-Mail-1-360954650 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzI4MTExOTE5WjAjBgkqhkiG9w0B CQQxFgQU82JiXYwrKZPsH+CBRY6x25DfodYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAPOhK+ku76bf9LyZJuijAK9UKOCpLWBFr8Z/uAST9qwYXPRRDVEb6DrmvUz7kvknSjCde xFvSUn6kERwIILrgcQoUKQxrcwYhHF9jEiB0VCxycdbWPqpOai0DImBWxxUvWzN7775b7PWwz22X d7DsN4mUhTXW4uSNcHXPmbXHlVLZUra8QGeN7uEx5PR27/c/lJ0S3xE6t2zzldCiN6VmUDCCNtWS 4s2OvI3Cyga4QGdqAdOyTDamfeFjCThq/uTJ0WcNH+fJR1cQMzoSLJOWCh65bYdosmKaF7znWkcC uay+QmNYksEI981vED3RFSXpKIQbQ+oBpABGSefCexhPlQAAAAAAAA== --Apple-Mail-1-360954650-- --===============0201605982== 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 -------------------------------------------------------------------- --===============0201605982==-- From ipv6-bounces@ietf.org Thu Jul 28 08:44:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy7kL-00052B-2V; Thu, 28 Jul 2005 08:44:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy7kI-00051X-1f for ipv6@megatron.ietf.org; Thu, 28 Jul 2005 08:44:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22332; Thu, 28 Jul 2005 08:44:14 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy8Fi-0003pa-Ab; Thu, 28 Jul 2005 09:16:47 -0400 Received: from ([128.244.96.158]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.14497071; Thu, 28 Jul 2005 08:43:51 -0400 Mime-Version: 1.0 (Apple Message framework v622) To: The IESG , Margaret Wasserman , Mark Townsley Message-Id: <7d7c736ed4e9cbd2325db5ab165baae1@innovationslab.net> From: Brian Haberman Date: Thu, 28 Jul 2005 08:43:50 -0400 X-Mailer: Apple Mail (2.622) X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SenderID:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> APL-TRU-Words:<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> APL-TRU-Substrings:<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Bob Hinden , IPv6 Mailing List Subject: 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: , Content-Type: multipart/mixed; boundary="===============1374271259==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1374271259== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-366026089; protocol="application/pkcs7-signature" --Apple-Mail-5-366026089 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Margaret & Mark, On behalf of the IPv6 WG, the chairs request the advancement of: Title : Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-03.txt Pages : 20 Date : 2005-7-15 as an Experimental document. The working group last call for this document ended on July 22, 2005. Regards, Brian & Bob IPv6 WG co-chairs --Apple-Mail-5-366026089 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzI4MTI0MzUwWjAjBgkqhkiG9w0B CQQxFgQUXLuygX+s+7KZJOzvKccx0fUpfxYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAk8Cgxzd3MplB8ZIvHrEccxeoHSrqIhqqZMFTeURNutF9fBWF9RDUOsQFyIWjCfkoJ4b9 6swoGNkdDqLvK4cJedU0iZAqxbnI7hMOOsUVOy3/Fs46tUmmUdzUrTJpPU+/oxiPCYbKQDLJnVsX hQ/Zq5a9XxZwsBf40ObEsaMorEKtF9efC6ba559IOmQcMGDVEbI9RvimM4bx+YsaX+1AJ5Tvi81A 87YLpsAEsj1R+V7aKRKeIjqAZLGCyytNkKmM7/suIIAQuHubMBtYqHR+5RnMgOpa0OSVYgSntzi0 oxH7YXSx3/dVSYIb22UX40WwEuZFzxOULt/f7mrm/5F74QAAAAAAAA== --Apple-Mail-5-366026089-- --===============1374271259== 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 -------------------------------------------------------------------- --===============1374271259==-- From ipv6-bounces@ietf.org Thu Jul 28 09:57:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy8tD-0002tJ-J2; Thu, 28 Jul 2005 09:57:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy8tC-0002t9-Dr for ipv6@megatron.ietf.org; Thu, 28 Jul 2005 09:57:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27868 for ; Thu, 28 Jul 2005 09:57:32 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy9Ob-0006IJ-8x for ipv6@ietf.org; Thu, 28 Jul 2005 10:30:05 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id GAA15741; Thu, 28 Jul 2005 06:57:10 -0700 (PDT) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6SDv9s18309; Thu, 28 Jul 2005 06:57:10 -0700 (PDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 28 Jul 2005 09:56:56 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2005 09:56:56 -0400 Message-ID: Thread-Topic: NSAP Address IPv6 option (request to WG chairs) Thread-Index: AcWTRBdkpHifudP3SRKMOpzNDlnIqgAOAsqQ From: "Manfredi, Albert E" To: "Brian E Carpenter" X-OriginalArrivalTime: 28 Jul 2005 13:56:56.0678 (UTC) FILETIME=[37877860:01C5937C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Subject: RE: NSAP Address IPv6 option (request to WG chairs) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Brian, Sounds good to me. Bert =20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Thursday, July 28, 2005 2:15 AM > To: Manfredi, Albert E > Cc: IPv6 > Subject: Re: NSAP Address IPv6 option (request to WG chairs) >=20 > Bert, >=20 > Over in another part of the universe, there's been quite a > discussion about the prudence required in the management > of limited namespaces, including IP options. As a result, I > don't want to leave what is basically garbage in the IANA > registry. So here is where I am at now, after the > discussion here: >=20 > 1. I will, right now, send an erratum note to the RFC Editor > to correct the omission in RFC 4048. >=20 > 2. I request the WG Chairs to make a consensus call on this > proposal: >=20 > The WG agrees to request the IANA to mark IPv6 > option type code 11-0-00011 =3D 195 decimal, C3 hexadecimal > as available for assignment. >=20 > Rationale: it's clear that this part of RFC 1888 was never > implemented by anybody, and we should not tie up a > namespace resource as a result. >=20 > Brian >=20 > Manfredi, Albert E wrote: > > Brian, if I have this right, you're talking about two possibilities > > here: > >=20 > > 1. Release the NSAPA destination option code, and have IANA=20 > mark it as > > "reserved," or > >=20 > > 2. Do nothing, which retains the NSAPA designation for that=20 > option code > > 0xC3. > >=20 > > Is there any practical value to changing the designation=20 > from NSAPA to > > "reserved"? If one takes work and the other does not, I'm=20 > not sure why > > bother. > >=20 > > In the future, can a request be made to the IANA to=20 > reassign that 0xC3 > > option code to some new use, citing RFC 4048 as a reason why this is > > okay to do? > >=20 > > Bert > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > >>Sent: Wednesday, July 27, 2005 4:56 AM > >>To: Templin, Fred L > >>Cc: IPv6; Bob Hinden > >>Subject: Re: NSAP Address IPv6 option > >> > >>I haven't seen any more discussion on this. > >> > >>It makes perfect sense to post errata, and as document > >>editor I can do that, but we also need to send a request to > >>IANA, as Bob suggested, and that presumably needs WG > >>consensus to be declared, which is outside my scope. > >> > >> Brian > >> > >>Templin, Fred L wrote: > >> > >>>Why not just post this as errata to RFC4048? > >>> > >>>Fred=20 > >>> > >>>-----Original Message----- > >>>From: Bob Hinden [mailto:bob.hinden@nokia.com]=20 > >>>Sent: Monday, July 11, 2005 10:18 AM > >>>To: Brian E Carpenter > >>>Cc: IPv6 > >>>Subject: Re: NSAP Address IPv6 option > >>> > >>>Brian, > >>> > >>>At 07:04 AM 07/11/2005, Brian E Carpenter wrote: > >>> > >>> > >>>>RFC 1888 defined a destination option called "NSAP Address" > >>>>with option type code 11-0-00011 =3D 195 decimal, C3 hexadecimal. > >>>> > >>>>Unfortunately, the IANA Considerations in RFC 4048 > >>>>faild to discuss this option. It is still listed at > >>>>http://www.iana.org/assignments/ipv6-parameters > >>>> > >>>>My opinion is that it can be released; I'm aware of no usage. > >>>> > >>>>Any objections? Can the WG Chairs suggest a procedure to avoid > >>>>the overhead of another trivial RFC? > >>> > >>> > >>>The chairs could send an email to the IANA (with cc's to=20 > >> > >>the IPv6 list > >> > >>>and=20 > >>>IESG) with something to the effect that since RFC4048 made RFC1888=20 > >>>historic, the destination option defined by RFC1888 is no=20 > >> > >>longer needed > >> > >>>and=20 > >>>should be marked as Reserved. This was the intention of=20 > >> > >>RFC4048, but > >> > >>>was=20 > >>>omitted in error. > >>> > >>>The only downside of this approach I can think of is that=20 > >> > >>there wouldn't > >> > >>>be=20 > >>>an RFC documenting the change. I am not sure this is a=20 > big deal in > >>>this case. > >>> > >>>Other opinions and/or suggestions? > >>> > >>>Bob > >>> > >>> > >>> > >>> > >>>----------------------------------------------------------- > --------- > >>>IETF IPv6 working group mailing list > >>>ipv6@ietf.org > >>>Administrative Requests:=20 > 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 > >>-------------------------------------------------------------------- > >> > >> > >=20 > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 >=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 Thu Jul 28 13:46:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCSh-0005qb-M9; Thu, 28 Jul 2005 13:46:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCSf-0005oP-7F for ipv6@megatron.ietf.org; Thu, 28 Jul 2005 13:46:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15768 for ; Thu, 28 Jul 2005 13:46:21 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyCy8-0004tp-PU for ipv6@ietf.org; Thu, 28 Jul 2005 14:18:59 -0400 Received: from ([128.244.96.158]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.14509935; Thu, 28 Jul 2005 13:45:48 -0400 Mime-Version: 1.0 (Apple Message framework v622) To: IPv6 WG Message-Id: <29300f0c4e6ecc98eb9fdc1ddd2c07bc@innovationslab.net> From: Brian Haberman Date: Thu, 28 Jul 2005 13:45:46 -0400 X-Mailer: Apple Mail (2.622) X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SenderID:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> APL-TRU-Words:<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> APL-TRU-Substrings:<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: Document status leading up to Paris X-BeenThere: ipv6@ietf.org 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="===============1464734665==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1464734665== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-384142799; protocol="application/pkcs7-signature" --Apple-Mail-3-384142799 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, As before, the below webpage contains the chairs' view of all the IPv6 WG documents. If you have comments/issues/questions please raise them on the mailing list. http://www.innovationslab.net/~brian/IETF63/IPv6/IPv6DocumentStatus.html Regards, Brian & Bob IPv6 WG co-chairs --Apple-Mail-3-384142799 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzI4MTc0NTQ3WjAjBgkqhkiG9w0B CQQxFgQUEwEOLx7TydzrUz6DINV5eo6BvXQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAYscZynAvApttTr/yoB7g3eCMQgQeOZS4k4SXs64fWj7D8iU7G5WEqf+v1H4eYcOAaSX8 DtM/S31wzMjYxQILICkA6rJbiVZh+m1TNIE30oM13LGp6PJteun+Q698tszDQSdX0gk1ip5PjZj4 f7LME4nQNz0wlidcRxLfLTBnFEvra5QQ1W3Ko5YTVErRtvuSQbWVmZNfGuGKXGZe1T233dmVA+bb XXsZVSAySFr0O5MH4ecnrLzz8J+tk0uhaY6qw5/o8Zfjk3yhACewTVtlj2SZXRbc3GLvfJ6aHJGV +OQ9BiT1jaC0R2lAraqU6Mvwba1DZ86L54TspAgA7Z3CPgAAAAAAAA== --Apple-Mail-3-384142799-- --===============1464734665== 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 -------------------------------------------------------------------- --===============1464734665==-- From ipv6-bounces@ietf.org Thu Jul 28 14:01:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCgt-0002wh-Mi; Thu, 28 Jul 2005 14:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCgr-0002wb-4J for ipv6@megatron.ietf.org; Thu, 28 Jul 2005 14:01:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17074 for ; Thu, 28 Jul 2005 14:01:03 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyDCL-0005Ny-IO for ipv6@ietf.org; Thu, 28 Jul 2005 14:33:39 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6SHvE55013759; Thu, 28 Jul 2005 20:57:15 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jul 2005 21:00:58 +0300 Received: from l5131412.nokia.com ([10.241.162.133]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Jul 2005 21:00:47 +0300 Message-Id: <6.2.1.2.2.20050728105403.02f5f0c0@daebe102.noe.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 28 Jul 2005 11:00:40 -0700 To: iana@iana.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 Jul 2005 18:00:47.0897 (UTC) FILETIME=[486A5090:01C5939E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Margaret Wasserman , Brian E Carpenter , ipv6@ietf.org Subject: Request change to IPv6 Option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Dear IANA, The IPv6 working group requests that the IANA change IPv6 option type C3 (hexadecimal) in registry: Internet Protocol version 6 (IPv6) Parameters http://www.iana.org/assignments/ipv6-parameters from: BINARY HEX act chg rest --- --- --- ----- C3 11 0 00011 NSAP Address [RFC 1888] to: 03 00 0 00011 [Unassigned] With the publication of RFC4048 that made RFC1888 historic, the destination option defined by RFC1888 is no longer needed can be made available for other usage. The working group is not aware of any operational usage of this option. This was the intention of RFC4048, but was omitted in error. A correction for this error has been submitted to the RFC-Editor to be listed as an erratum for RFC 4048. Bob Hinden & Brian Haberman IPv6 Working Group 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 Jul 28 14:01:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyChH-00036T-Pi; Thu, 28 Jul 2005 14:01:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyChG-00035v-Ib for ipv6@megatron.ietf.org; Thu, 28 Jul 2005 14:01:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17103 for ; Thu, 28 Jul 2005 14:01:29 -0400 (EDT) Received: from mail-red.bigfish.com ([216.148.222.61] helo=mail16-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyDCj-0005OJ-3e for ipv6@ietf.org; Thu, 28 Jul 2005 14:34:04 -0400 Received: from mail16-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail16-red-R.bigfish.com (Postfix) with ESMTP id 24E553ECBAC for ; Thu, 28 Jul 2005 18:01:17 +0000 (UTC) X-BigFish: VC Received: by mail16-red.bigfish.com (MessageSwitch) id 1122573672122470_15275; Thu, 28 Jul 2005 18:01:12 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail16-red.bigfish.com (Postfix) with ESMTP id E71773EBDD4 for ; Thu, 28 Jul 2005 18:01:11 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id j6SI1AUZ006744 for ; Thu, 28 Jul 2005 13:01:10 -0500 (CDT) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j6SI1A722372 for ; Thu, 28 Jul 2005 13:01:10 -0500 (CDT) Received: from PLSWB06C.ad.sprint.com ([208.10.70.231]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 13:01:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Jul 2005 13:01:09 -0500 Message-ID: <305877A001ED2447B5F5C40FC5774E9901108A84@PLSWB06C.ad.sprint.com> Thread-Topic: I requested to be taken off the ipv6 ietf org email list, but I am continuing to receive emails. Please help. Thanks. Thread-Index: AcWTnlVu9Dv9xNdyRku+JvIa//3TdQ== From: "Boyer, Karen E [NTK]" To: X-OriginalArrivalTime: 28 Jul 2005 18:01:09.0646 (UTC) FILETIME=[5560F2E0:01C5939E] X-Spam-Score: 1.6 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: I requested to be taken off the ipv6 ietf org email list, but I am continuing to receive emails. Please help. Thanks. X-BeenThere: ipv6@ietf.org 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="===============0465168596==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0465168596== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5939E.55666339" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5939E.55666339 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------_=_NextPart_001_01C5939E.55666339 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I requested to be taken off the ipv6 ietf org email list, but I = am continuing to receive emails. Please help. Thanks.
------_=_NextPart_001_01C5939E.55666339-- --===============0465168596== 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 -------------------------------------------------------------------- --===============0465168596==-- From ipv6-bounces@ietf.org Fri Jul 29 14:18:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyZRj-0005cJ-KQ; Fri, 29 Jul 2005 14:18:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyZRf-0005c8-A7 for ipv6@megatron.ietf.org; Fri, 29 Jul 2005 14:18:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27906 for ; Fri, 29 Jul 2005 14:18:51 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyZxK-0001Rv-EF for ipv6@ietf.org; Fri, 29 Jul 2005 14:51:39 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j6TIIcxk254336 for ; Fri, 29 Jul 2005 14:18:38 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6TIIbrD435090 for ; Fri, 29 Jul 2005 12:18:37 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6TIIbTF022086 for ; Fri, 29 Jul 2005 12:18:37 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-220-115.mts.ibm.com [9.65.220.115]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j6TIIafm022035; Fri, 29 Jul 2005 12:18:37 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j6TIIVUd005727; Fri, 29 Jul 2005 14:18:31 -0400 Message-Id: <200507291818.j6TIIVUd005727@cichlid.raleigh.ibm.com> To: Bob Hinden In-Reply-To: Message from Bob Hinden of "Thu, 28 Jul 2005 11:00:40 PDT." <6.2.1.2.2.20050728105403.02f5f0c0@daebe102.noe.nokia.com> Date: Fri, 29 Jul 2005 14:18:31 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Margaret Wasserman , iana@iana.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: Request change to IPv6 Option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Minor point: > from: > BINARY > HEX act chg rest > --- --- --- ----- > C3 11 0 00011 NSAP Address [RFC 1888] > to: > 03 00 0 00011 [Unassigned] Would it be good to include as a reference, a pointer to RFC 4048, as in: 03 00 0 00011 [Unassigned] [RFC 4048] Even though 4048 doesn't mention this explicitely, that document surely explains why this is unassigned (in case anyone cares to look). 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 Jul 29 15:54:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyavi-00072O-4z; Fri, 29 Jul 2005 15:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyavZ-0006wq-Ch for ipv6@megatron.ietf.org; Fri, 29 Jul 2005 15:54:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04920 for ; Fri, 29 Jul 2005 15:53:51 -0400 (EDT) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DybRH-00043e-I0 for ipv6@ietf.org; Fri, 29 Jul 2005 16:26:40 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6TJri0T006019; Fri, 29 Jul 2005 22:53:46 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jul 2005 22:53:44 +0300 Received: from l5131412.nokia.com ([10.241.162.133]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Jul 2005 22:53:45 +0300 Message-Id: <6.2.1.2.2.20050729125219.02e85998@daebe102.noe.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 29 Jul 2005 12:53:21 -0700 To: "Thomas Narten" From: Bob Hinden In-Reply-To: <200507291818.j6TIIVUd005727@cichlid.raleigh.ibm.com> References: <200507291818.j6TIIVUd005727@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Jul 2005 19:53:46.0076 (UTC) FILETIME=[3AF019C0:01C59477] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Margaret Wasserman , ipv6@ietf.org, iana@iana.org, Bob Hinden , Brian E Carpenter Subject: Re: Request change to IPv6 Option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thomas, >Would it be good to include as a reference, a pointer to RFC 4048, as >in: > > 03 00 0 00011 [Unassigned] [RFC 4048] > >Even though 4048 doesn't mention this explicitely, that document >surely explains why this is unassigned (in case anyone cares to look). Good point. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Jul 30 18:09:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyzWC-0006dZ-F4; Sat, 30 Jul 2005 18:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyzWA-0006dI-D3; Sat, 30 Jul 2005 18:09:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01741; Sat, 30 Jul 2005 18:09:16 -0400 (EDT) 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 1Dz026-0003C3-Dl; Sat, 30 Jul 2005 18:42:19 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2005 15:09:03 -0700 X-IronPort-AV: i="3.95,155,1120460400"; d="scan'208"; a="327549375:sNHT32322660" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6UM93Is027742; Sat, 30 Jul 2005 15:09:03 -0700 (PDT) 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.211); Sat, 30 Jul 2005 18:09:02 -0400 Received: from 10.86.240.20 ([10.86.240.20]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([144.254.231.73]) with Microsoft Exchange Server HTTP-DAV ; Sat, 30 Jul 2005 22:09:01 +0000 Received: from 98.20.242.10.in-addr.arpa by email.cisco.com; 30 Jul 2005 22:09:44 +0000 From: Ralph Droms To: shim6@psg.com, mipshop@ietf.org, ipv6@ietf.org, mip6@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 30 Jul 2005 18:09:43 -0400 Message-Id: <1122761384.5750.29.camel@98.20.242.10.in-addr.arpa> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 30 Jul 2005 22:09:02.0703 (UTC) FILETIME=[4B3CD7F0:01C59553] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Subject: Report on IPv6 network renumbering at v6ops WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At the v6ops WG meeting (1400 Mon), there will be a report from the participants in a recently completed project in IPv6 network renumbering. I've included a description of the report below. Anyone interested in hearing the results of this project and participating in a discussion about what we should consider as next steps to build on these results is invited to attend. - Ralph Droms Discussion of IPv6 Network Renumbering -------------------------------------- Baker, et al., have written a description a process for IPv6 network renumbering in "Procedures for Renumbering an IPv6 Network without a Flag Day" . Teams from University of Southampton, the JOIN Project at University of Muenster, Renater, PSNC and Loria-Inria have conducted a series of experiments in network renumbering, based on the process described by Baker. Results from the study include operational experience with the network renumbering procedure, identification of the effects of network renumbering on network management tools and other applications and recommendations for updates to the network renumbering procedure, and advice for network administrators, application developers and others to ameliorate the effects of network renumbering. The purpose of this discussion is to disseminate results and conclusions from these experiments, stimulate discussion of IPv6 network renumbering and consider future work in this area. The draft agenda for the discussion is: Introduction Ralph Droms ( 5 mins) Prior art and tools, backbone JOIN/Univ. Muenster ( 5 mins) renumbering and BGP issues, SOHO renumbering Enterprise experiments and Univ. Southampton ( 5 mins) recommendations Router renumbering protocol, renumbering Renater ( 5 mins) procedure gap analysis Impact of renumbering on management PSNC ( 5 mins) tools Maintaining management plane during Loria-Inria ( 5 mins) renumbering, monitoring renumbering Conclusions Ralph Droms ( 5 mins) Discussion (15 mins) Next steps? Ralph Droms (10 mins) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jul 31 00:00:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz50G-00076o-AL; Sun, 31 Jul 2005 00:00:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz50E-00076j-B0 for ipv6@megatron.ietf.org; Sun, 31 Jul 2005 00:00:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12802 for ; Sun, 31 Jul 2005 00:00:40 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dz5WE-0005JI-Ed for ipv6@ietf.org; Sun, 31 Jul 2005 00:33:46 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id B459157C for ; Sun, 31 Jul 2005 00:00:22 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 31 Jul 2005 00:00:22 -0400 Message-Id: <20050731040022.B459157C@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.63% | 12 | 15.96% | 79764 | iljitsch@muada.com 15.85% | 13 | 13.43% | 67128 | jinmei@isl.rdc.toshiba.co.jp 7.32% | 6 | 12.60% | 62953 | perry@coders.net 6.10% | 5 | 4.10% | 20468 | fred.l.templin@boeing.com 3.66% | 3 | 4.91% | 24553 | ipng@69706e6720323030352d30312d31340a.nosense.org 3.66% | 3 | 4.60% | 22997 | brian@innovationslab.net 3.66% | 3 | 3.65% | 18220 | rdroms@cisco.com 3.66% | 3 | 2.78% | 13914 | pekkas@netcore.fi 3.66% | 3 | 2.53% | 12621 | bob.hinden@nokia.com 2.44% | 2 | 3.37% | 16862 | stig.venaas@uninett.no 2.44% | 2 | 2.93% | 14624 | albert.e.manfredi@boeing.com 2.44% | 2 | 2.80% | 13997 | stephen@sprunk.org 2.44% | 2 | 2.73% | 13642 | brc@zurich.ibm.com 1.22% | 1 | 3.31% | 16545 | a@arifumi.net 2.44% | 2 | 1.94% | 9720 | keiichi@iijlab.net 2.44% | 2 | 1.44% | 7221 | soohong.park@samsung.com 1.22% | 1 | 1.47% | 7370 | syam@samsung.com 1.22% | 1 | 1.35% | 6751 | nuno.mgarcia@siemens.com 1.22% | 1 | 1.10% | 5488 | karen.e.boyer@mail.sprint.com 1.22% | 1 | 1.08% | 5388 | ronald.pashby.ctr@navy.mil 1.22% | 1 | 1.01% | 5059 | sra+ipng@hactrn.net 1.22% | 1 | 0.98% | 4874 | hirose@comm.yamaha.co.jp 1.22% | 1 | 0.96% | 4819 | smadanapalli@gmail.com 1.22% | 1 | 0.95% | 4756 | samita.chakrabarti@eng.sun.com 1.22% | 1 | 0.90% | 4479 | ted.lemon@nominum.com 1.22% | 1 | 0.89% | 4467 | tjc@ecs.soton.ac.uk 1.22% | 1 | 0.88% | 4417 | brett.pentland@eng.monash.edu.au 1.22% | 1 | 0.87% | 4334 | anoop.ghanwani@hp.com 1.22% | 1 | 0.85% | 4231 | francis.dupont@enst-bretagne.fr 1.22% | 1 | 0.83% | 4150 | narten@us.ibm.com 1.22% | 1 | 0.75% | 3731 | lican.huang@cs.cardiff.ac.uk 1.22% | 1 | 0.73% | 3654 | sharkey@zoic.org 1.22% | 1 | 0.68% | 3400 | mkt@ecs.soton.ac.uk 1.22% | 1 | 0.64% | 3214 | support@paypal.com --------+------+--------+----------+------------------------ 100.00% | 82 |100.00% | 499811 | 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 ipv6-bounces@ietf.org Sun Jul 31 17:39:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzLXB-0005up-AG; Sun, 31 Jul 2005 17:39:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzLX9-0005tn-65; Sun, 31 Jul 2005 17:39:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19598; Sun, 31 Jul 2005 17:39:44 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzM3G-00015N-VU; Sun, 31 Jul 2005 18:13:01 -0400 Received: from impact.jinmei.org (unknown [2001:688:ffff:20:69d5:743:d5e4:3a77]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BF7E515218; Mon, 1 Aug 2005 06:39:17 +0900 (JST) Date: Mon, 01 Aug 2005 06:39:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org, dhcwg@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Thu, 28 Jul 2005 01:37:48 +0900, >>>>> JINMEI Tatuya said: > 2) Ability for a host to get all desired and available DHCP > configuration with a single DHCP message exchange > - if a host wants HCB, it sends an HCB request (Solicit) and receives > HCB and/or ICB replies > - if a host wants ICB, it sends an ICB request (Information-request) > and receives ICB replies (snip) > Requirement 2 seems least controversial. In my understanding, this is > basically for removing redundant probe packets or hopeless timeouts > for unavailable service. In particular, we wanted to avoid scenario > where an HCB client continues sending Solicits even if there is no HCB > server but an ICB-only server, and even if the client can somehow > benefit from the "ICB part" excluding addresses. Such a case is most > likely a result from temporary dead servers or configuration errors, > but we seem to have agreed that we want to deal with such cases. > Requirement 2 can be met through some extensions to RFC3315 and > RFC3736. Assuming we basically agreed that the basic analysis I showed in my previous message, I'd like to discuss more details about 'solutions'. The followings are possible extensions to DHCPv6 I've seen so far: A. make an ICB-only server reply to Solicit with an Advertise including NoAddrsAvail and other configuration information (just like a Reply to Information-request) B. make an HCB client accept an Advertise even if it includes NoAddrsAvail, if it gets no other Advertise including addresses, the Advertise also includes other configuration information, and the client can benefit from that information C. allow an HCB client to fallback from HCB to ICB after some timeout D. allow an HCB client to perform HCB and ICB concurrently Extensions A and B help when the RA signal indicates the availability of HCB (whether the signal is "1-bit" or "2-bit (for HCB and ICB)") but no HCB server is actually available for some reason. One debatable point is that Extension A requires a modification (an additional feature) to ICB-only servers, which are expected to be light-weight (note, however, that the ICB-only servers will still be stateless even with the extension). Extensions C and D concern an HCB client for which there is only an ICB-only server that does not support extension A (i.e., it's a kind of backward compatibility). We have multiple choices about these extensions. - If our consensus is we don't have to care about such compatibility, we don't need either of those. - If we really need something like those, then Extensions C and D are almost exclusive with some tradeoffs: + Extension C does not consume redundant bandwidth since ICB is not invoked if a working HCB server exists. + But it takes more time for the client to get other configuration information via ICB if no HCB server but ICB server exists. + Extension D ensures that the client can always get at least other configuration information as quickly as possible. + However, it consumes more bandwidth since the client will always send ICB requests regardless of the existence of an HCB server. The followings are my personal conclusions regarding the extensions. I believe we can agree that extension B is acceptable. Whether extension A is also acceptable or not probably depends on whether we can accept "complicating" ICB-only servers. I guess we need inputs from implementors, but, as one implementor of DHCPv6, I think this is an acceptable modification. Regarding extensions C and D, I can live with either: extension C only, extension D only, or none of those, expecting we can introduce extensions A and B (then newer implementations don't need either extension C or D). But I'd slightly prefer introducing extension C. This can be suboptimal (in terms of fallback delay) compared to extension D, but I guess the advantage of less consumption of bandwidth would be preferred because this is just a workaround with older (without extension A) ICB-only servers. And I still believe providing the workaround will help. 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 --------------------------------------------------------------------