CINXE.COM
Tech Stuff - IPv6
<!DOCTYPE html> <html lang="en-us"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <link rel="icon" href="http://www.zytrax.com/favicon.ico"> <title>Tech Stuff - IPv6</title> <meta name="description" content="Zytrax Tech Stuff - IPv6 Address format and global unicast adress formats. SLAAC configuration. Page includes an IPv6 address calculator."> <meta name="keywords" content="ZYTRAX, Tech Stuff, IPv6, IPv6 address notation, IPv6 slash notation, IPv6 address calculator, SLAAC, IPv6 Link-local addrss format, IPv4 6to4 "> <!-- this page originated from http://www.zytrax.com/tech/protocols/ipv6.html --> <!-- HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 3.5.21022; .NET CLR 1.0.3705; .NET CLR 1.1.4322) --> <style type="text/css"> <!-- /* ZYTRAX STYLE SHEET */ /* google maps */ /* v\:* {behavior:url(#default#VML);} */ /* tag modifiers */ a {text-decoration:none;color:gray;} a:hover {text-decoration:underline;} a:hover.p-f-s {color:black} a:hover.a-n {text-decoration:none;} body {background-color:white;color:black;margin:0px;padding:0px;font:normal 1.0em Verdana,Arial, Helvetica, sans-serif;} code {border:1px solid lightgray;background:mintcream;color:black;font-family:"Courier New", monospace;padding:0 2px} div.l-f table{width:100%;padding:4px;} h1 {font-size:1.5em;;border-width:0 0 5px 0;border-style:solid;border-color:LightGray;padding:4px;color:black} h2 {border-width:0 0 5px 0;border-color:LightGray;border-style:solid;font-size:1.3em;font-weight:bold;padding:4px;color:black} h3 {border-width:0 0 3px 0;border-color:LightGray;border-style:solid;font-size:1.1em;padding:4px;color:black;} h4 {border-width:0 0 2px 0;border-color:LightGray;border-style:solid;font-size:1.0em;padding:2px;color:black;} h5 {border-width:0 0 2px 0;border-color:LightGray;border-style:solid;font-size:1.0em;font-weight:bold;color:black;padding:4px;} h6 {border-width:0 0 1px 0;border-color:LightGray;border-style:solid; font-size:80%;color:black;padding:4px;} pre {white-space:pre-wrap;} img {border:0;} img.center {display:block;margin-left:auto;margin-right:auto;} img.right {display:block;float:right;} img.left {display:block;float:left;} form {border:1px solid #ccc;} input {border:1px solid #999;background:#9bf;} textarea {border:1px solid #999;background:#9bf;} table {margin: 0 auto;} table.t-m-n > tbody > tr > td {border:1px solid #ccc;padding:4px;} table.t-m-s > tbody > tr > td {border:1px solid #ccc;padding:4px;} table.p-m-n > tbody > tr > td {padding:4px;border-collapse:collapse;} table.p-m-s > tbody > tr > td {padding:4px;border-collapse:collapse;} tr {vertical-align:top;} /* end tag modifiers - Printer friendly */ .adv {margin-right:auto;margin-left:auto;width:728px;} .l-b {position:absolute;top:0px;left:0px;font-size:80%;border:0;background:white;color:gray;height:100px;z-index:9;width:100%;} div.l-r #layout {visibility:visible;} div.l-l-fp #layout {visibility:visible;} .l-l {position:absolute;top:100px;left:6px;width:110px;font:10pt Verdana,Helvetica, Arial, sans-serif;z-index:1;} .l-c {margin:105px 170px 0px 125px;padding:4px 20px;border-width:0 1px; border-style:solid; border-color:LightGray; z-index:5; line-height:1.3em;} .l-r {position:absolute;top:100px;right:0;width:160px;background:white;z-index:2;font-size:80%;} /* end printer friendly - begin divs generic (cross browser) */ .i-2 {background: url(../../images/info.gif) no-repeat top left;border-width: 3px 0 3px 0; border-style:solid;border-color:#bbb;font-size:10pt;padding:10px 10px 10px 60px;margin:10px;} .i-3 {background: url(../../../images/info.gif) no-repeat top left;border-width: 3px 0 3px 0; border-style:solid;border-color:#bbb;font-size:10pt;padding:10px 10px 10px 60px;margin:10px;} .l-c-i {padding:10px;} .l-l-fp {position:absolute;top:95px;left:6px;width:120px;z-index:10;text-align:right;font-size:80%;} .l-r-fp {position:absolute;top:95px;right:6px;width:150px;z-index:2;font-size:80%;} .l-f-m {} .l-f {margin:0 200px 0 125px;} .l-p {margin:10px;padding:4px;font:10pt Verdana,Helvetica, Arial, sans-serif;} .l-100 {width:100%;margin:0;} .w-2 {background: url(../../images/warning.gif) no-repeat top left;border-width: 3px 0 3px 0; border-style:solid;border-color:#bbb;font-size:10pt;padding:10px 10px 10px 60px;margin:10px;} .w-3 {background: url(../../../images/warning.gif) no-repeat top left;border-width: 3px 0 3px 0; border-style:solid;border-color:#bbb;font-size:10pt;padding:10px 10px 10px 60px;margin:10px;} /* end divs - begin nav pop-outs */ .n-l-c {color:black;} .n-l1 {padding:0;margin:0;list-style:none;width:100px;} .n-l1p {padding:0;margin:0;list-style:none;text-align:right;color:#339;} .n-l1p-e {font-size:9pt;margin:0;text-align:right;line-height:1.2em;position:relative;color:#339;} .n-l1-e {text-align:right;margin:0;padding:2px;position:relative;} .n-t1-e,.n-t2-e,.n-t3-e,.n-m-l1 {text-align:left;margin:0;padding:2px 5px;border:1px solid black;border-width:1px 1px 0 1px;position:relative;} .n-t1-es,.n-t2-es,.n-t3-es {text-align:left;margin:0;padding:2px 5px;border:1px solid black;border-width:1px 1px 0 1px;position:relative;background:#eee;} .n-t1-v {position:absolute;display:none;padding:0;margin:0;list-style:none;top:100%;right:0;width:100px; border-bottom:1px solid black;background:white;} .n-t1-vr,.n-m-u1 {position:absolute;display:none;padding:0;margin:0;list-style:none; top:100%;right:0;width:100px;border-bottom:1px solid black;background:white;} .n-t2,.n-t3 {position:absolute;display:none;padding:0;margin:0;list-style:none;top:0;right:100%;width:120px;border-bottom:1px solid black;background:white;} /* end pop-up styles - begin nav effects */ .g-c-n:hover {background:#eee;} .g-c-s:hover {background:#eee;} /* W3c pop-ups - selectors ignored by MSIE 6- */ div.n-m:hover > ul {display:block;} div.n-t0:hover > ul {display:block;} li.n-t1-e:hover > ul {display:block;} li.n-t1-es:hover > ul {display:block;} li.n-t1-e:hover, li.n-t1-es:hover,li.n-t2-e:hover,li.n-t2-es:hover,li.n-t3-e:hover,li.n-m-l1:hover {background:#ccc;} li.n-t2-e:hover > ul {display:block;} li.n-t2-es:hover > ul {display:block;} .n-l1-e:hover > ul {display:block;} .n-l1p-e:hover > ul {display:block;} .n-l1-es:hover > ul {display:block;} .n-l2-e:hover > ul {display:block;} .n-l2-es:hover > ul {display:block;} .n-l3-e:hover > ul {display:block;} .n-l3-es:hover > ul {display:block;} li.n-l1-e:hover,li.n-l1p-e:hover,li.n-l2-e:hover,li.n-l2-es:hover, li.n-l3-e:hover, li.n-l3-es:hover,li.n-l4-e:hover {background:#ccc;} /* end pop-up effects - begin generic (cross browser) alpha */ .arrows {font-size:250%;} .a-n {text-decoration:none;} .at {font-family:Verdana,sans-serif;font-size:9pt;margin:0px;text-indent:8px;} .b-1 {font-family:Verdana, sans-serif;} .button {background:#ddd;border:3px outset black;} .b-lg {background-color:#eee;} .b-r {border-width:0 0 0 1px;border-color:#336;border-style:solid;width:150px;} .b-l {border-width:0 1px 0 0;border-color:#336;border-style:solid;width:110px;} .b-b-s {border:1px solid black;} /* color styles */ .c-r, .red {color:red;} .c-b, .blue {color:blue;} .c-lg {color:LightGray;} .c-g {color:gray;} /* end color styles */ .d {font-family:Verdana,sans-serif;font-size:9pt;margin:0px;} .dd {position:absolute;left:0;top:0; font-family:Tahoma,sans-serif;font-size:9pt; visibility:hidden;background:lime;color:black;margin:0px;border:black solid 1px;padding:2px;} .f-d {font-weight:bold;} .f-b-n {border:0;} /* most browsers use an unacceptably small monospace default font */ .g-c-n,.g-b-n {font:110% "Courier New",monospace;border-style:solid;border-color:#ccc;border-width: 1px 1px 1px 5px;background-color:#9bf;padding:5px; color:black;} .g-c-s,.g-b-s,.codegray {font: 80% "Courier New",monospace;border-style:solid;border-color:#ccc;border-width: 1px 1px 1px 5px; background-color:#9bf;padding:5px; color:black;width:inherit;} .g-h-n, .g-s-b {background:#9bf;color:#339;padding:4px;font-size:100%;font-weight:normal;border:1px solid #ccc;} .g-h-nn {background:#9bf;color:#339;padding:4px; font-size:100%;font-weight:normal;} .g-h-ng,.section {background:#339;color:white;font:bold Verdana,sans-serif;padding:4px; text-decoration:none;} .g-h-s {background:#9bf;color:#339;padding:4px; font-size:80%;font-weight:normal;border:1px solid #ccc;} .g-h-ss {background:#9bf;color:#339;padding:4px; font-size:80%;font-weight:normal;} .g-n {text-decoration:none;color:white;} .g-i1-n {margin:5px 5px 5px 20px;} .g-i2-n {margin:5px 5px 5px 30px;} .g-i3-n {margin:5px 5px 5px 40px;} .g-l-n {list-style:none;} .g-sb-n {color:blue;font-size:8pt;line-height:150%;margin:2px;} .g-s-n {background-color:#eee;color:black;font-size:10pt; text-decoration:none;} .h-b {background:#ddd;color:black;font-weight:bold;} .h-150 {line-height:1.5em;} .i-h {margin:5px 5px 10px 60px;padding:5px;} .i-n {border-width: 3px 0 3px 0; border-style:solid;border-color:#bbb;font-size:10pt;padding:10px 10px 10px 60px;margin:10px;} .i-s {border-width: 3px 0 3px 0; border-style:solid;border-color:#bbb;font-size:8pt;margin:10px 10px 10px 60px;padding:10px;} .i-u {width:27px;} .n-l {position:fixed;left:6px;width:110px;} .n-l-fp {left:6px;width:110px;} .n-l-f {font-size:1.0em;margin:2px;text-align:right;line-height:1.2em;color:black;} .n-l-f a {color:black;} .m-h5 {margin:0.5em 0;} .m-h20 {margin:2.0em 0;} .n-b-l {font:1pt Verdana, Arial, Helvetica, sans-serif;border-width:0 0 1px 0;border-style:solid;border-color:#CCF;margin:0px;padding:0px;} .n-l-s {font-size:80%;visibility:hidden;} .n-m {font-size:130%;margin:0;padding:0;float:right;position:relative;} .n-t0 {float:right;position:relative;} .n-t-t {text-align:right;padding:1px 1px 8px 1px;margin:0;} .o-n {list-style:none;} .p-b {background:#eee;text-indent:3em;} .p-m-n,.norm {font-size: 100%;border-spacing:0;border-collapse:collapse;} .p-m-s { font-size:80%;border:0;border-spacing:0;border-collapse:collapse;} .q-i-2 {background: url(../../images/quotes-open.gif) no-repeat top left;} .q-s {border-width: 0 0 0 6px;border-style:solid;border-color:#acf;font-size:8pt;margin:10px 10px 10px 60px;padding:10px;} .t-b-s {font:8pt "Courier New",monospace;border-style:solid;border-color:#ccc;border-width: 1px;background-color:#acf;padding:5px; color:black;} .t-b-n {font:10pt "Courier New",monospace;border-style:solid;border-color:black;border-width: 1px;background-color:#acf;padding:5px; color:black;} /* link/href styles */ .t-dd:hover {background:#ddd;} .w-db:hover {background:#ddd;} .t-ba {color:#aaa;font-weight:bold;} .t-gb {color:blue;background:#eee;} .t-dr {color:red;text-decoration:none;} .t-dw {color:#666;text-decoration:none;} .t-db,.t-dd {color:blue;text-decoration:none;} .t-da {color:black;} .w-db,.t-dn {text-decoration:none;} /* begin text styles */ .t-b {font-size:120%;} .t-b200 {font-size:200%;} .t-c, .center {text-align:center;} .t-g {background:#eee;} .t-h {} div.t-h:hover > div {display:block;} .t-h-1 {display:none;background:#eee;padding:5px;} .t-i {font-style:italic;} .t-l {text-align:left;} .t-n, .g-e-t, .g-e-d {font-size:100%;font-weight:normal;} .t-o {font-weight:bold;} .t-r {text-align:right;} .t-s {font-size:80%;} .t-ss {font-size:60%;} /* table styles */ .t-t-l {margin:0;} .t-td1-l,.t-td1 {border-style:solid;border-width:5px 0 0 0;border-color:#ddd;padding:3px 3px 8px 5px;} .t-td2-l,.t-td2 {border-style:solid;border-width:5px 0 0 0;border-color:#acf;padding:3px 3px 8px 5px;} .t-m {background:#ccc;color:blue;text-decoration:none;} .t-m-n {font-size: 100%;border: 2px solid #ccc;border-spacing:0;border-collapse:collapse;} .t-m-s {font-size:80%;border: 2px solid #ccc;border-spacing:0;border-collapse:collapse;} .vital {font-family:Tahoma,Arial, sans-serif;font-size:12pt;background-color:#ddd; color:black;border-color:red;} /* visibility */ .v-h {visibility:hidden;} /* width styles */ .w-450 {width:450px;} .w-350 {width:350px;} .w-300 {width:300px;} .w-250 {width:250px;} .w-200 {width:200px;} .w-180 {width:180px;} .w-150 {width:150px;} .w-120 {width:120px;} .w-100 {width:100px;} .w-80 {width:80px;} .w-88 {width:88px;} .w-50 {width:50px;} .w-32 {width:32px;} .w-27 {width:27px;} .w-20 {width:20px;} .w-10 {width:10px;} .w-11pc {width:11%;} .w-6pc {width:6%;} /* Gecko/W3C specific */ abbr[title]:after {content:"";} abbr[title]:hover:after {content:" (" attr(title)")";} /* W3C pop-ups */ .n-l2,.n-l3,.n-l4 {position:absolute;display:none;padding:0;margin:0;list-style:none;top:0;left:100%;width:120px;border-bottom:1px solid black;background:#EEE;font:8pt Verdana,Helvetica, Arial, sans-serif} .n-l2-e,.n-l3-e,.n-l4-e {text-align:left;margin:0;padding:2px 5px;border:1px solid black;border-width:1px 1px 0 1px;position:relative;} .n-l2-es,.n-l3-es,.n-l4-es {text-align:left;margin:0;padding:2px 5px;border:1px solid black;border-width:1px 1px 0 1px;position:relative;background:white;} /* end - start expand divs */ .v-f {display:none;} .v-o {display:block;} /* end expand divs */ #toplogo {float:left;vertical-align:bottom;} .g-ci-s {font:8pt "Courier New",monospace;border-style:solid;border-color:#ccc;border-width: 1px 1px 1px 5px; background-color:#acf;color:black;} .jp-h-n {position:absolute;left:50%;top:50%;text-indent:4px;font-family:Verdana,sans-serif;font-size:10pt; visibility:hidden;background:#EEEEEE;color:blue;text-decoration:none;} .n-l-u {font-family:Verdana,sans-serif;top:60px;left:6px;width:110px;background:white;} .n-l-l {font-size: 9pt;color:black;text-align:right;line-height:150%;} .n-p-f {color:#336;font:9pt/16pt Verdana,sans-serif;text-decoration:none;text-indent:6px;} .n-p-n {background:#EEE;color:#336;font:9pt Verdana,sans-serif;text-indent:6px;} .n-p-n a {text-indent:6px;display:block;} .n-p-o {font:10pt Verdana,sans-serif; background:#DDD;color:blue;text-decoration:none;height:16pt;} .n-t-n {color:#336;font:10pt Verdana,sans-serif;text-decoration:none;margin:0;padding:0;} .n-t-s {color:white;font: 8pt Verdana,sans-serif;text-decoration:none;padding:0 3px 0 0} .n-t-sr {color:#336;font: 8pt Verdana,sans-serif;text-decoration:none;padding:0 3px 0 0} .p-b-h {visibility:hidden;} .p-n-h {position:absolute;left:0;top:0;text-indent:4px;font-family:Verdana,sans-serif;font-size:small; visibility:hidden;background:#EEE;color:blue;text-decoration:none;border:1px blue solid;width:110px;} .p-f-s {font-family: Verdana, sans-serif; font-size:8pt; color:silver; background:white;text-decoration:none;} --> </style> <style type="text/css" media="print"> <!-- /* ZYTRAX STYLE SHEET PRINT TEMPLATE */ .l-l {display:none;} .l-r {display:none;} .l-c {width:600px;margin:0;padding:30px 10px 5px 10px; border-width:0;} .l-f {margin:5px;} .n-t-t {display:none;} .n-t0 {display:none;} .adv {display:none;} --> </style> <script type="text/javascript"> <!-- // copyright ZYTRAX, Inc. 1994 - 2014 // you may use this javascript code at your own risk. // we would like you to keep the copyright statement intact but don't insist on it. // If you make improvements mail us a copy or make it available on your own web site. // global variables var topall = new Array(2); var lownav = new Array(2); var lowpop = new Array(2); var rightnav = new Array(2); var rightpop = new Array(2); var x = 0; // global menu level var way = 'h'; var menu = null; var menus = null; var pop1 = new Array(2); var fs = 1.0; var days = new Array(7); var months = new Array(12); days = ["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"]; months = ["January","February","March","April","May","June","July","August","September","October","November","December"]; function showtime() { var thistime = ""; var nowtime ="" var nowam = "AM"; var now = new Date(); var nowhour = now.getHours(); if (nowhour > 12) { nowam = "PM"; nowhour = nowhour - 12; } else if (nowhour == 0){ nowhour = 12; } var nowminutes = now.getMinutes(); if (nowminutes < 10 ){ nowminutes = "0" + nowminutes; } nowtime = nowhour + ":" + nowminutes + " " + nowam; thistime = days[now.getDay()] + " " + now.getDate() + " " + months[now.getMonth()] + " " + now.getFullYear() + ", " + nowtime; return thistime; } // -- W3C DOM specific code - first choice always function lock(num){ // lock relies on a style which end with -l rollover = document.getElementById("l" + num); if(rollover){ cn = rollover.className if((pos = cn.lastIndexOf("-")) != -1){ bcn = cn.substring(0,pos + 1); scn = cn.substring(pos +1); if(scn == "f" || scn == "o"){ rollover.className = bcn + "l"; } } } } function fontchange(fix) { x = document.getElementsByTagName("div"); for(i = 0; i < x.length; i++) { if(x[i].className == "l-c"){ if(x[i].style.fontSize == ""){ fs = 1.0; x[i].style.fontSize = "1.0em"; } if(fix == "d"){ if(fs <= 0.8){ break; }else{ fs = parseFloat(fs - 0.1); x[i].style.fontSize = fs + "em"; } }else{ if(fs >= 1.5){ break; }else{ fs = parseFloat(fs + 0.1); x[i].style.fontSize = fs + "em"; } } break; } } } function toggle(tid){ var dis; var disa; if(document.getElementById){ dis = document.getElementById(tid); disa = document.getElementById(tid + 'a'); }else{ dis = document.all.tid; disa = document.all.tid + 'a'; } if(dis.style.display == 'block'){ dis.style.display = 'none'; disa.style.display = 'block'; }else{ dis.style.display = 'block'; disa.style.display = 'none'; } } function gotourl($url) { window.location = $url; } function mailus(mbox,stub,subject) { mail = "mailto:"+mbox+"@"+stub; if(subject != ""){ mail = mail+"?SUBJECT="+"A-Z: "+subject; } window.location = mail; return; } // W3C compliant uses CSS popups not JS //--> </script> </head> <body> <!-- Page Header plus top nav bar --> <div class="l-b"> <!--if expr="!${isMob}" --> <a href="http://www.zytrax.com"><img id="toplogo" src="http://www.zytrax.com/images/zytrax-logo-info.png" alt="ZYTRAX Info Logo"></a> <!-- desktop browsers --> <p class="n-t-t"><a href="http://www.zytrax.com/feedback.htm" class="n-t-sr">mail us</a> | <a href="http://www.zytrax.com/run/mailpage.php" class="n-t-sr">mail this page</a></p> <div class="n-t0"> <a href="http://www.zytrax.com/Company/contacts.html" class="n-t-sr">contact us</a> </div> <div class="n-t0"> <a href="http://www.zytrax.com/training/" class="n-t-sr">training</a> | </div> <div class="n-t0"> <a href="http://www.zytrax.com/tech/" class="n-t-sr">tech stuff</a> | <ul class="n-t1-v"> <li class="n-t1-es"><a href="http://www.zytrax.com/tech/" class="t-da">tech stuff</a> <!-- tertiary pop-outs --> <ul class="n-t2"> <li class="n-t2-e"><a title="collection of technology stuff" href="http://www.zytrax.com/tech/" class="t-da">tech stuff</a></li> <li class="n-t2-es t-da">web stuff <ul class="n-t3"> <li class="n-t3-e"><a title="collection of web based technology stuff" href="http://www.zytrax.com/tech/web/" class="t-da">web stuff</a></li> <li class="n-t3-e"><a title="collection of UA strings for most browsers" href="http://www.zytrax.com/tech/web/browser_ids.htm" class="t-da">browser ids</a></li> <li class="n-t3-e"><a title="collection of mobile UA strings" href="http://www.zytrax.com/tech/web/mobile_ids.html" class="t-da">mobile ids</a></li> <li class="n-t3-e"><a title="our HTML5 page conversion process and thoughts" href="http://www.zytrax.com/tech/css/html5.html" class="t-da">HTML5 Convert</a></li> <li class="n-t3-e"><a title="how we do server-side browser sniffing with apache" href="http://www.zytrax.com/tech/web/browser_sniffing.html" class="t-da">browser sniffing</a></li> <li class="n-t3-e"><a title="apache environmental variables" href="http://www.zytrax.com/tech/web/env_var.htm" class="t-da">apache env's</a></li> <li class="n-t3-e"><a title="apache server side includes - extensive notes and examples" href="http://www.zytrax.com/tech/web/ssi.htm" class="t-da">apache ssi</a></li> <li class="n-t3-e"><a title="our css pop-up/pop-down/flyout menus for Gecko/Opera/MSIE" href="http://www.zytrax.com/tech/css/workarounds.html#popout" class="t-da">pop-outs (css)</a></li> <li class="n-t3-e"><a title="most of those annoying HTML entity codes that we forget all the time" href="http://www.zytrax.com/tech/web/entities.html" class="t-da">html entities</a></li> </ul> </li> <li class="n-t2-es t-da">open guides <ul class="n-t3"> <li class="n-t3-e"><a href="http://www.zytrax.com/books/" class="t-da">open guides</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/books/dns" class="t-da">dns guide</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/books/ldap" class="t-da">ldap guide</a></li> </ul> </li> <li class="n-t2-e"><a title="Decimal to Hexidecimal to Binary conversion - even Octal!" href="http://www.zytrax.com/tech/protocols/hex.html" class="t-da">Dec>Hex>Bin</a></li> <li class="n-t2-es t-da">survival stuff <ul class="n-t3"> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/survival/" title="a series of survival guides for some popular open source software" class="t-da">survival stuff</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/survival/ssl.html" class="t-da">ssl/tls & x.509</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/survival/asn1.html" class="t-da">ASN.1</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/survival/kerberos.html" class="t-da">kerberos</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/survival/postfix.html" class="t-da">postfix</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/survival/cron.html" class="t-da">cron</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/survival/encryption.html" class="t-da">cryptography</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/survival/wxwidgets.html" class="t-da">wxWidgets</a></li> </ul> </li> <li class="n-t2-es t-da">audio stuff <ul class="n-t3"> <li class="n-t3-e"><a title="Pages about Digital Audio, Primers, Calculator, Equalization, FFT" href="http://www.zytrax.com/tech/audio/" class="t-da">audio stuff</a></li> <li class="n-t3-e"><a title="Fundamentals, harmonics, overtone, partials, loudness, ADSR envelopes" href="http://www.zytrax.com/tech/audio/sound.html" class="t-da">sound primer</a></li> <li class="n-t3-e"><a title="Sound digitization, time domain, frequency domain" href="http://www.zytrax.com/tech/audio/digital-sound.html" class="t-da">digital sound</a></li> <li class="n-t3-e"><a title="common frequencies of instruments and in life" href="http://www.zytrax.com/tech/audio/audio.html" class="t-da">frequencies</a></li> <li class="n-t3-e"><a title="equalization principles, octaves, sound metering and FFT" href="http://www.zytrax.com/tech/audio/equalization.html" class="t-da">equalization</a></li> <li class="n-t3-e"><a title="Acoustic caculators for musical notes and FFT bin frequencies" href="http://www.zytrax.com/tech/audio/calculator.html" class="t-da">calculators</a></li> <li class="n-t3-e"><a title="Yet another audio glossary" href="http://www.zytrax.com/tech/audio/glossary.html" class="t-da">glossary</a></li> </ul> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/web/regex.htm" class="t-da">regex stuff</a></li> <li class="n-t2-es t-da">cable stuff <ul class="n-t3"> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/layer_1/" class="t-da">cable stuff</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/layer_1/cables/tech_lan.htm" class="t-da">lan wiring</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/layer_1/cables/mixed.html" class="t-da">lan & telephone</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/layer_1/cables/tech_rs232.htm" class="t-da">rs232 stuff</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/layer_1/cables/heavy.htm" class="t-da">serial primer</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/pc/serial.html" class="t-da">usb 3.2 & firewire</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/pc/monitors.htm" class="t-da">displays</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/layer_1/cables/cables_jacks.htm" class="t-da">modular jacks</a></li> </ul> </li> <li class="n-t2-es t-da">protocol stuff <ul class="n-t3"> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/protocols/" class="t-da">protocol stuff</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/protocols/tcp.html" class="t-da">tcp-udp-icmp</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/protocols/ip-classes.html" class="t-da">ipv4</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/protocols/ip-classes.html#calculator" class="t-da">ipv4 Calculator</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/protocols/ipv6.html" class="t-da">ipv6</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/protocols/ipv6.html#calculator" class="t-da">ipv6 Calculator</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/protocols/isdn" class="t-da">isdn-bri</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/protocols/lan" class="t-da">802 lan</a></li> <li class="n-t3-e"><a href="http://www.zytrax.com/tech/ss7" class="t-da">ss7 & sigtran</a></li> </ul> </li> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/pc/" class="t-da">pc stuff</a></li> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/wireless/" class="t-da">wireless stuff</a></li> <li class="n-t2-es t-da">css stuff <ul class="n-t3"> <li class="n-t3-e"><a title="collection of css notes and experiences including css menus and css liquid layout" href="http://www.zytrax.com/tech/css/" class="t-da">css stuff</a></li> <li class="n-t3-e"><a title="Notes on our experience with converting to css based liquid layouts - including blow by blow css" href="http://www.zytrax.com/tech/css/layoutnotes.html" class="t-da">css liquid design</a></li> <li class="n-t3-e"><a title="we have used css menus since mid-2003 - blow-by-blow implementation notes" href="http://www.zytrax.com/tech/css/workarounds.html#popout" class="t-da">css menus</a></li> <li class="n-t3-e"><a title="some practical solutions on using css" href="http://www.zytrax.com/tech/css/workarounds.html" class="t-da">css notes</a></li> <li class="n-t3-e"><a title="css shortforms at a glance" href="http://www.zytrax.com/tech/css/shortcut.html" class="t-da">css short-forms</a></li> <li class="n-t3-e"><a title="css selectors and quick overview with links to the W3C specs" href="http://www.zytrax.com/tech/css/syntax.html" class="t-da">css overview</a></li> </ul> </li> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/codes.htm" class="t-da">ascii codes</a></li> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/data_rates.htm" class="t-da">data rate stuff</a></li> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/telephony/" class="t-da">telephony stuff</a></li> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/mech/" class="t-da">mech. stuff</a></li> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/protocols/hex.html" class="t-da">Dec>Hex>Bin</a></li> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/lang/" class="t-da">language stuff</a></li> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/electronics/" class="t-da">electronic stuff</a></li> <li class="n-t2-e"><a href="http://www.zytrax.com/tech/rfcs/" class="t-da">rfc stuff</a></li> </ul> </li> <li class="n-t1-e"><a href="http://www.zytrax.com/security/" class="t-da">Security</a></li> </ul> </div> <!-- close div l-b --> </div> <!-- begin body table --> <div class="l-c"> <!-- generic tech ads --> <p class="adv"> <script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script> <!-- Browser Leaderboard --> <ins class="adsbygoogle" style="display:inline-block;width:728px;height:90px" data-ad-client="ca-pub-9419480011552853" data-ad-slot="9281933980"></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script> </p> <h1>Tech Stuff - Ipv6</h1> <p>Version 6 of the IP Protocol. Defined in <a href="rfc2460.txt" class="t-db">RFC 2460</a> (and updated by <a href="rfc5095.txt" class="t-db">RFC5095</a> and <a href="rfc5722.txt" class="t-db">RFC5722</a>). Everything about IPv6 is BIG. An <a href="ip-classes.html" class="t-db">IPv4</a> address is 32 bits, an IPv6 address is 128 bits. This is about the number where each blade of grass on the planet could have its own IPv6 address.</p> <p>IPv6 has been around since at least 1995 but the <a href="ip-classes.html#cidrnat" class="t-db">CIDR</a> initiative of the mid-nineties pushed back any, then pressing, need for IPv6's increased address range. The can was effectively kicked down the road. In retrospect this was probably a Good Thing ™ since much of the recent (2010/2015) IPv6 work has been to reduce IPv6 address complexity, interworking and overall functionality.</p> <p>IPv6 is big and complex in comparison with IPv4. This fact alone will keep users from implementation if they have any choice in the matter. Nevertheless, the internet is rapidly approaching the time - primarily due to IPv4 address depletion - when there is little choice but to move to IPv6. The transition will be accompanied by much yelling, screaming, gnashing of teeth and grim resignation. It is not helped by the constant roll-back and fiddling with the IPv6 specifications.</p> <div class="t-h"><p><span class="t-g">More Info</span></p> <div class="t-h-1"> <p>Here are some of the reasons we need to transition to IPv6:</p> <ol> <li>The <a href="http://www.3gpp.org" target="_blank" class="t-dd">3GPP (3rd Generation Partnership Project)</a> decision to use IPv6 for increasingly functional mobile equipment.</li> <li>8 of the 13 DNS root-servers are advertising both IPv4 and IPv6 access (abfhjklm - as of 2010).</li> <li>Increasing demand for end user address transparency, for example, VoIP.</li> <li>Widespread availability of IPv6 protocol stacks for almost all major OS platforms.</li> <li>Increasingly dire warnings (2010) from the major Regional Internet Registries (RIRs), responsible for Internet address allocation, about depletion of IPv4.</li> </ol> <p>The IPv4 vs IPv6 debate is also about the bigger issue of <i>end user transparency</i> vs NAT. Between those who see NAT as being inherently evil - since it hides end user addresses thus removing address transparency (using a variety of simple to gruesome techniques) - and those who see NAT as being a life saving technology that may indefinitely postpone the need for IPv6.</p> <p>To be truly useful IPv6 must also finally remove the need for end users to know anything about their IP address as a matter of routine - simply because it will be impossible for any sane human being to remember one of these gruesome strings of digits. Imagine asking your Father to read his IPv6 address over the phone. Got the picture. DNS and DHCPv6 can work seemlessly to make the IP address disappear at the user level and auto-configuration (stateless or SLAAC configuration) can simplify address allocation. For IPv6 to work we must treat any need for a visible IP address as a system failure.</p> <p>IPv6 may have been, to use an unattributed quote, "too much, too early" and certainly the latest RFCs try and back-pedal from some of the earlier specification constraints and functionality (frequently making them even more complex to read if that is possible). Nevertheless, there are a significant number of implementations, proving IPv6 is a production ready technology. Much of the new IPv6 work appearing in the RFCs is, apart from routine maintenance, concerned with the impact of IPv6 in the tightly constrained mobile world.</p> </div> </div> <p>It is noted that <a href="rfc6540.txt" class="t-db">RFC 6540</a> (published April 2012) now formally suggests that best practice protocol stacks should now include both IPv6 and IPv4. While IPv6 and IPv4 have been available, for many years, with mainstream OSs (Linux, BSD, Windows and others) and, due to its application in the mobile world, Android and other mobile centric OSs, most network boxes (DSL/cable modems) are still IPv4 only. High quality Open Source IPv6 stacks and this nudging from the IETF may change this. Then again, perhaps holding one's breath may not be a sensible strategy just yet since it will be many years before all that IPv4 NAT investment used by most ISPs will obsolete IPv4 functionality.</p> <p>You need to be fairly comfortable with Hex stuff to handle IPv6 (<a href="hex.html" class="t-db">quick overview of Hexadecimal, Binary and Decimal</a>)</p> <h3 id="contents">Contents</h3> <ol style="list-style:none"> <li><a href="#intro" class="t-db">IPv6 Overview</a></li> <li><a href="#ipv6" class="t-db">IPv6 Address Notation</a></li> <li><a href="#slash" class="t-db">IPv6 Prefix or Slash Notation</a></li> <li><a href="#types" class="t-db">IPv6 Address Types</a></li> <li><a href="#global" class="t-db">IPv6 Global Unicast Address Format</a></li> <li><a href="#unicast" class="t-db">IPv6 End-User Address Format</a></li> <li><a href="#calculator" class="t-db">IPv6 Address Calculator</a></li> <li><a href="#ipv6-config" class="t-db">IPv6 Configuration Options</a></li> <li><a href="#stateless" class="t-db">IPv6 Stateless Address AutoConfiguration (SLAAC)</a></li> <li><a href="#link-local" class="t-db">IPv6 Link-Local Address Format</a></li> <li><a href="#eui64" class="t-db">EUI-64 Address formation for SLAAC and Link-Local</a></li> <li><a href="#multicast" class="t-db">IPv6 Multicast Address Format</a></li> <li><a href="#ipv6-ipv4" class="t-db">IPv6 - IPv4 Interworking</a></li> <li><a href="#ipv6-over-ipv4" class="t-db">IPv6 over IPv4 Interworking (6to4)</a></li> <li><a href="#frame" class="t-db">IPv6 Frame Format</a></li> <li><a href="#header" class="t-db">IPv6 Header Format</a></li> <li><a href="#order" class="t-db">IPv6 Order of Headers</a></li> <li><a href="#extension" class="t-db">IPv6 Extension Headers</a></li> <li><a href="ipv6-formats.html#discovery" class="t-db">IPv6 Discovery</a></li> <li><a href="ipv6-formats.html#icmpv6" class="t-db">IPv6 ICMP</a></li> <li><a href="ipv6-formats.html#icmpv6-ping-cmd" class="t-db">IPv6 ping6 command</a></li> <li><a href="ipv6-formats.html#icmpv6-traceroute-cmd" class="t-db">IPv6 traceroute6 command</a></li> <li><a href="#rfcs" class="t-db">IPv6 RFCs</a></li> </ol> <h2 id="overview">IPv6 Overview</h2> <p>First things first. Each PC - more properly each network interface - may have more than one IPv6 address - IPv6 is naturally multi-homed. Second, an IPv6 address has a scope, that is, it can be restricted to a single LAN or a private network or be globally unique. The following table defines the types of IPv6 addresses that can be supported and contrasts them with their closest IPv4 functional equivalent.</p> <table class="t-m-s"> <tr class="g-h-n"> <td class="w-100">IPv6 Name</td> <td>Scope/Description</td> <td>IPv4 Equivalent</td> <td>Notes</td> </tr> <tr > <td>Link-Local</td> <td>Local LAN only. Automatically assigned based on MAC. Cannot be routed outside local LAN.</td> <td>No real equivalent. Assigned IPv4 over ARP'd MAC.</td> <td>Scoped address concept new to IPv6. Multicast may also be scoped to link-local (<a href="rfc4489.txt" class="t-db">RFC 4489</a>). <a href="#link-local" class="t-db">Format</a>.</td> </tr> <tr > <td>Site-Local</td> <td>Optional. Local Site only. Cannot be routed over Internet. Assigned by user.</td> <td>Private network address with multi-homed interface is closest equivalent.</td> <td>Scoped address concept new to IPv6. Unlike the IPv4 private network address the IPv6 device can have, and most likely will have, Link-Local, Site-Local and a Global Unicast address. Site-Local while continuing to exist in the IPv6 specification is the subject of on-going work in the IETF and is currently not supported. The address block used for this purpose has been marked Reserved by IANA.</td> </tr> <tr > <td>Global Unicast</td> <td>Globally unique. Fully routable. Assigned by IANA/Regional Internet Registries (RIRs).</td> <td>Global IP address.</td> <td>IPv6 and IPv4 similar but IPv6 can have <i>other</i> scoped addresses. <a href="#global" class="t-db">Format</a>.</td> </tr> <tr > <td>Multicast</td> <td>One-to-many. Hierarchy of multicasting.</td> <td>Similar to IPv4 Class D.</td> <td>Significantly more powerful than IPv4 version. No broadcast in IPv6, replaced by multicast. Multicast may also be scoped to link-local (<a href="rfc4489.txt" class="t-db">RFC 4489</a>). <a href="#multicast" class="t-db">Format</a>.</td> </tr> <tr > <td>Anycast</td> <td>One-to-nearest. Uses Global Unicast Addresses. Routers only. Discovery uses.</td> <td>Unique protocols in IPv4, for example, IGMP.</td> <td>Addresses are indistinguishable froma normal unicast address. Anycast (router-to-router) is also used with IPv4 addresses, specifically with DNS root servers, though there may be other instances.</td> </tr> <tr > <td>Loopback</td> <td>Local interface scope.</td> <td>Same as IPv4 127.0.0.1</td> <td>Same function</td> </tr> </table> <h2 id="ipv6">IPv6 Address Notation</h2> <p>An IPv6 address consists of 128 bits - an IPv4 address consists of 32 bits - and is written as a series of 8 hexadecimal strings separated by colons. (Format defined by <a href="rfc4291.txt" class="t-db">RFC 4291</a> and updated by <a href="rfc5952.txt" class="t-db">RFC 5952</a>) Examples:</p> <pre class="g-c-s"> # all the following refer to the same address 2001:0000:0234:C1AB:0000:00A0:AABC:003F # leading zeros can be omitted 2001:0:234:C1AB:0:A0:AABC:3F # not case sensitive - any mixture allowed 2001:0:0234:C1ab:0:A0:aabc:3F </pre> <p>One or more zeros entries can be omitted entirely but only once in an address. The user can choose the most efficient place to omit multiple zero entries. Examples:</p> <pre class="g-c-s"> # raw ipv6 address 2001:0000:0234:C1AB:0000:00A0:AABC:003F # address with single 0 dropped 2001::0234:C1ab:0:A0:aabc:003F # alternate version - address with single 0 dropped 2001:0:0234:C1ab::A0:aabc:003F # the following is INVALID 2001::0234:C1ab::A0:aabc:003F </pre> <p>Multiple zeros can be omitted entirely but only once in an address. Examples:</p> <pre class="g-c-s"> # omitting multiple 0's in address 2001:0:0:0:0:0:0:3F # can be written as 2001::3F # lots of zeros (loopback address) 0:0:0:0:0:0:0:1 # can be written as ::1 # all zeros (unspecified a.k.a unassigned IP) 0:0:0:0:0:0:0:0 # can be written as :: # but this address 2001:0:0:1:0:0:0:3F # cannot be reduced to this 2001::1::3F # INVALID # instead it can only be reduced to 2001::1:0:0:0:3F # or 2001:0:0:1::3F </pre> <p>Experiment using the <a href="#calculator" class="t-db">IPv6 Address Calculator</a>.</p> <p>A hybrid format may be used when dealing with <a href="#ipv6-ipv4" class="t-db">IPv6 - IPv4</a> addresses called an IPv4-Mapped IPv6 Address (<a href="rfc4291.txt" class="t-db">RFC 4291</a> - updated by <a href="rfc5952.txt" class="t-db">RFC 5952</a> and <a href="rfc6052.txt" class="t-db">RFC 6052</a>) where the normal IPv4 dotted decimal notation may be used after the first 6, 16 bit address elements:</p> <pre class="g-c-s"> # generic IPv6-IPv4 format x.x.x.x.x.x.d.d.d.d # example of an IPv4 mapped IPv6 address # with an IPv4 number of 192.168.0.5 2001:db8:0:0:0:0:FFFF:192.168.0.5 # or using zero elimination 2001.db8::FFFF:192.168.0.5 </pre> <p>Experiment using the <a href="#calculator" class="t-db">IPv6 Address Calculator</a>.</p> <p><b>Notes:</b></p> <ol> <li><p>The FFFF element in the 6th position is fixed and must be present (see also <a href="rfc6052.txt" class="t-db">RFC 6052</a> for a peculiar shifted version of this format when used with certain IPv4/IPv6 translators).</p></li> <li><p>To avoid publication of a global IPv4 the example above shows a private (non-globally unique) IPv4 address purely to illustrate the principle but the IPv4 address used in IPv4-Mapped IPv6 must always be globally unique address.</p></li> </ol> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="slash">IPv6 Prefix or Slash Notation</h2> <p>IPv6 uses a similar / (forward slash) notation to IPv4 CIDR (Classless Interdomain Routing) which describes the number of contiguous bits used in its netmask. Formally this way of writing an address is called an IP prefix but more commonly called the slash format. Examples:</p> <pre class="g-c-s"> # single user address 2001:db8::1/128 # normal user IPv6 address allocation # allows the user to control the low order 80 bits 2001:db8::/48 # values only required to cover the prefix FE8::/10 # or top 3 bits only with fixed value 001 (binary) 2::/3 </pre> <p>Experiment using the <a href="#calculator" class="t-db">IPv6 Address Calculator</a>.</p> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="types">IPv6 Address Types</h2> <p>The type of IP address is defined by a variable number of the top bits known as the <i>binary prefix</i> (BP). Only as many bits as required are used to identify the address type as shown in the following table (defined in <a href="rfc4291.txt" class="t-db">RFC 4291</a>):</p> <table class="t-m-s"> <tr class="g-h-n"> <td>Use</td> <td class="w-120">Binary Prefix</td> <td class="w-50">Slash</td> <td>Description/Notes</td> </tr> <tr > <td>Unspecified</td> <td>00...0</td> <td>::/128</td> <td>IPv6 address = 0:0:0:0:0:0:0:0 (or ::) Used before an address allocated by DHCP (equivalent of IPv4 0.0.0.0)</td> </tr> <tr > <td>Loopback</td> <td>00...1</td> <td>::1/128</td> <td>IPv6 address = 0:0:0:0:0:0:0:1 (or ::1) Local PC Loopback (equivalent of IPv4 127.0.0.1)</td> </tr> <tr > <td>Multicast</td> <td>1111 1111</td> <td>FF::/8</td> <td><a href="#multicast" class="t-db">Format</a>. There is now a <a href="#local-multicast" class="t-db">link-local multicast format</a> defined by <a href="rfc4489.txt" class="t-db">RFC 4489</a>.</td> </tr> <tr > <td>Link-Local unicast</td> <td>1111 1110 10</td> <td>FE8::/10</td> <td>Local LAN scope. Lower bits (EUI-64) created from MAC address or other Interface Identifier. <a href="#link-local" class="t-db">Format</a>. There is now a <a href="#local-multicast" class="t-db">link-local multicast format</a> defined by <a href="rfc4489.txt" class="t-db">RFC 4489</a>.</td> </tr> <tr > <td>Site-Local unicast</td> <td>1111 1110 11</td> <td>FEC::/10</td> <td>Local Site scope. Lower bits assigned by user. This binary prefix has been marked Reserved by IANA to reflect the currently unsupported state of Site-Local addressing.</td> </tr> <tr > <td>Global Unicast</td> <td>All other values</td> <td>2::/3</td> <td>A note in RFC 3513 recommended that IANA should continue to allocate only from the binary prefix 001 (as in RFC 2373 version) but <a href="rfc3587.txt" class="t-db">RFC 3587</a> obsoletes this recommendation. <a href="#global" class="t-db">Format</a>.</td> </tr> </table> <p>The revised definition is a conceptual change and is both more flexible than the previous (RFC 2373/RFC 3513) definition if a tad confusing. <a href="#ipv6-ipv4" class="t-db">IPv4</a> and NSAP prefixes are still allowed for but are now simply unicast addresses. Subsequent changes (from RFC 3513 to RFC 4291) seem to be trying to remove some of the restrictions previously imposed such that RFCs now use the distinction between a binary prefix of 000 (covering IPv6 mapped IPv4, unassigned and loopback) and not 000 (all other unicast) rather than explicity using 001 as previously. The obsolescence of address block assignment from the previous binary prefix 001 seems to be of a theoretical nature since all current <a href="http://www.iana.org/assignments/ipv6-unicast-address-assignments/" class="t-db">IANA address block assigments</a> are still from this prefix.</p> <p>Experiment using the <a href="#calculator" class="t-db">IPv6 Address Calculator</a>.</p> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="global">IPv6 Global Unicast Address Format</h2> <p>The IPv6 Global Unicast 128 bits was historically divided into a 48 bit <i>global routing prefix</i> (a.k.a <i>site prefix</i>) which is assigned by various authorities, a 16 bit subnet ID and 64 bits which the Interface ID (IID). The 16 bit subnet ID and IID (a total of 80 bits) is normally assigned and used by the user. While this structure is still the <b>normal</b> address allocation, the standards (<a href="rfc4291.txt" class="t-db">RFC 4291</a>) now define both the global routing prefix and the subnet ID to be of variable length (and using a total of 64 bits) in order to allow greater flexibility for the RIRs in allocating addresses. The formal structure is therefore:</p> <table class="t-m-s"> <tr class="g-h-s"> <td class="w-80">Name</td> <td class="w-50">Size</td> <td>Description/Notes</td> </tr> <tr > <td class="w-120">GRP</td> <td>Variable</td> <td>Global Routing Prefix. Variable format depending on the Binary Prefix, for instance, if 001 - Global Unicast Address (assigned by IANA) uses this <a href="#unicast" class="t-db">format</a>. See note about current standards structure above. Normally this part is 48 bits in length but - depending on RIR policies - can be as long as 56 bits. </td> </tr> <tr > <td>subnet ID</td> <td>Variable</td> <td>Used for subnet routing. See notes about current standards structure above. Normally this part is 16 bits in length but - depending on RIR policies - can be as low as 8 bits or 0 is the user only requires a single subnet. </td> </tr> <tr > <td>interface ID</td> <td>64 bits</td> <td>The unique interface identifier (host address equivalent in IPv4). </td> </tr> </table> <p>The current IPv6 address allocation policy adopted by the various Regional Internet Registries should be based on the IETF/IAB recomendation (in <a href="rfc3177.txt" class="t-db">RFC 3177</a>) which allows for:</p> <table class="t-m-s"> <tr class="g-h-s"> <td class="100">Name</td> <td>Allocation</td> <td>Description/Notes</td> </tr> <tr > <td>Normal User</td> <td>/48</td> <td>May cover home or business use. The user controls the full 80 bits addresses comprising the subnet ID (16 bits) and Interface ID (IID - 64 bits). Regional (RIRs) or Local Internet Registries (LIRs) seem to be able to allocate a /56 in which case the subnet is defined to be 8 bits and the IID remains, as normal, 64 bits. It is not clear under what circustances /56 addresses are allocated other than they provide another level of allocation flexibility for the RIRs/LIRs. </td> </tr> <tr > <td>Single subnet</td> <td>/64</td> <td>Where it is known that only a single subnet can be used the user is assigned control of the interface ID part only </td> </tr> <tr > <td>Single Device</td> <td>/128</td> <td>Where it is known that only one device can be used the user is assigned a single interface ID </td> </tr> </table> <p>The justification for this, seemingly generous, address allocation policy is that the 45 address bits (48 bit global routing prefix - 3 bit binary prefix) still allow ~35 trillion /48 allocations (contrasted with the earth's population prediction of a mere 9 billion by 2050).</p> <p>Experiment using the <a href="#calculator" class="t-db">IPv6 Address Calculator</a>.</p> <h2 id="unicast">IPv6 End-User Address Format</h2> <p>End-User addresses are assigned from the Global Unicast pool (current <a href="http://www.iana.org/assignments/ipv6-unicast-address-assignments/" class="t-db">IANA IPv6 address block assignments</a>). In addition a list of special assigments was created by <a href="rfc4773.txt" class="t-db">RFC 4773</a>. The IETF 6bone used a special range of 3FFe::/16 but the 6bone is disbanded and the address range has been returned to the IANA Reserved pool. The 128 bits breakdown as follows:</p> <table class="t-m-s"> <tr class="g-h-n"> <td colspan="3"><i>Global Routing Prefix (GRP)</i> of 48 - 64 bits - assigned by IANA/RIR/LIR.</td> </tr> <tr class="g-h-s"> <td class="w-120">Name</td> <td class="w-50">Size</td> <td>Description/Notes</td> </tr> <tr > <td>reserved</td> <td>3 bits</td> <td>001 (or simply not 000 in some RFCs) - Global Unicast Address prefix (assigned by IANA) </td> </tr> <tr > <td>-</td> <td>Variable</td> <td>Prior to RFC 4291 this field was 45 bits in length and for the global unicast address defined a strict hierarchy of Aggregators using the terms, TLA (Top Level Aggregator), sub-TLA and NLA (Next Level Aggregator). RFC 4291 obsoleted this structure and essentially leaves any sub format to Regional Internet Registries (RIRs). In addition the subnet ID field (previously defined to be 16 bits in length) is also defined to of variable length thus many of the current IPv6 specifications confusingly refer to the whole of this address space plus the subnet ID simply as the subnet ID to this field. <a href="http://www.iana.org/assignments/ipv6-unicast-address-assignments/" class="t-db">IPv6 Global unicast address block assigments are maintained by IANA</a>. The size of the IANA IPv6 address block assigment varies from /12 to /23.</td> </tr> <tr class="g-h-n"> <td colspan="3">80 - 64 bits - typically assigned by the user</td> </tr> <tr class="g-h-s"> <td>Name</td> <td>Size</td> <td>Description/Notes</td> </tr> <tr > <td>subnet ID</td> <td>16 bits</td> <td>Used for subnet routing. See notes above. This field is formally (within RFC 4291) of variable length and while 16 bits is the normal allocation it can be - depending on the RIR policies - as low as 8 bits or 0 is the user only requires a single subnet.</td> </tr> <tr > <td>interface ID (IID)</td> <td>64 bits</td> <td>End User Interface (EUI-64). Equivalent to IPv4 host address - since this field alone is bigger that the whole IPv4 address space it is fairly generous! When used in <b>stateless (SLAAC)</b> configurations the EUI-64 address part may be created from the MAC as described below in <a href="#link-local" class="t-db">Link Local</a>. <a href="rfc4941.txt" class="t-db">RFC 4941</a> defines a method by which temporary (pseudo random) addresses (EUI-64) may be created in order to create privacy (or anonymity).</td> </tr> </table> <p>Experiment using the <a href="#calculator" class="t-db">IPv6 Address Calculator</a>.</p> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="ipv6-config">IPv6 Configuration</h2> <p>IPv6 systems are typically multi-homed by default and have a <a href="#link-local" class="t-db">link-local address</a> configured by the host and may have a <a href="#global" class="t-db">global unicast address</a> which may be configured by one of four methods:</p> <ol> <li>Stateful - Statically assigned = manual configuration</li> <li>Stateful - DHCPv6 - Automatically assigned</li> <li><a href="#stateless" class="t-db">Stateless</a> - Automatically assigned (SLAAC)</li> <li><a href="#stateless" class="t-db">Stateless</a> - Automatically assigned (SLAAC) with DHCPv6 support for DNS information.</li> </ol> <h2 id="stateless">IPv6 Stateless Autoconfiguration (SLAAC)</h2> <p>IPv6 systems may be configured to provide global unicast addresses using Stateless Address AutoConfiguation (SLAAC - defined by <a href="rfc4862.txt" class="t-db">RFC 4862</a>) using what is called generically the Neighborhood Discovery Protocol (NDP). Stateless autoconfiguration requires a router to be present but not a DHCP server. The process of creating a stateless IPv6 address is as follows:</p> <ol> <li><p>Host sends a <a href="ipv6-formats.html#router-solicitation" class="t-db">Router Solicitation</a> message</p></li> <li><p>Host waits for a <a href="ipv6-formats.html#router-advert" class="t-db">Router Advertisement</a> message.</p></li> <li><p>Host takes top bits as defined in the Prefix Information of the <a href="ipv6-formats.html#router-advert" class="t-db">Router Advertisement message</a> and combines it with the 64 bit EUI-64 address (in the case of Ethernet this is created from the <a href="lan/802_3_frame.htm#mac" class="t-db">MAC address</a> using <a href="#eui64" class="t-db">this process</a>) to create a Global Unicast address. The host also uses the source IP address - in the IP header - of the Router Advertisement (RA) message as its default gateway address. And since <a href="rfc6106.txt" class="t-db">RFC 6106</a> can also obtain information about DNS service from the RA messages.</p> <p><a href="rfc4941.txt" class="t-db">RFC 4941</a> defines a method by which temporary (essentially pseudo-random from the interface derived EUI-64 address) addresses may be created in order to create privacy (or anonymity). RFC 4941 defines the default state of anonymous address creation as being off. If you wish anoymous access under IPv6 you may have to look for a specific configuration variable in your system to turn the anonymous feature on.</p></li> <li><p>Host then performs a Duplicate Address Detection (DAD) to ensure the address is unique (and on any of the anaonymous addresses generated by RFC 4941 procedures). If this check fails the host immediately aborts the autoconfiguration process and must be manually configured.</p></li> </ol> <p><b>Example:</b></p> <pre class="g-c-s"> # Interface MAC 00-40-63-ca-9a-20 # IPv6 Interface ID (EUI-64) # Note: bit 7 (U/L) set - see link local notes ::0240:63FF:FECA:9A20 # or ::240:63FF:FECA:9A20 # Prefix from Router Advertisement 2001:db8::/64 # global Unicast address 2001:db8::240:63FF:FECA:9A20 </pre> <p><b>Notes:</b></p> <ol> <li><p>In stateless autoconfiguration (SLAAC) the global unicast (public address) and the default router address are configured automatically. Additional address information, such as DNS addresses, are not and must be provided by either DHCPv6 or manual configuration.</p></li> <li><p>When using SLAAC the low order 64 bits (EUI-64) of the <a href="#link-local" class="t-db">Link Local</a> and the Global Unicast address will be identical since both are <a href="#eui64" class="t-db">created using the same process</a>.</p></li> </ol> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="link-local">IPv6 Link-Local Address Format</h2> <p>Link-Local addresses are automatically assigned by the end user equipment and require no external configuration. Format defined by <a href="rfc4291.txt" class="t-db">RFC 4291</a> Section 2.5.6. The address format uses a unique binary prefix (FE8::/10) and the remaining bits (118) are built from the local interface identifier. In the case of ethernet (<a href="rfc2464.txt" class="t-db">RFC 2464</a>) the MAC (48 bits) is used to create the EUI-64 value as shown below. Each physical layer supported has a separate RFC for example, FDDI, IEEE 802.15.4 etc. defining, among other things, how the link-local address is created. If an interface identifier has more than 118 bits the link-local address cannot be generated and the unit must be manually configured. Link-local addresses are not routable globally (outside the local LAN/network - however that is defined). The 128 bits of a link-local address for an ethernet interface breakdown as follows:</p> <table class="t-m-s"> <tr class="g-h-n"> <td colspan="3">10 bits - Binary Prefix</td> </tr> <tr class="g-h-s"> <td class="w-80">Name</td> <td class="w-50">Size</td> <td>Description/Notes</td> </tr> <tr > <td>Binary Prefix</td> <td>10 bits</td> <td>1111 1110 10 or FE8::/10 Link-Local Prefix </td> </tr> <tr class="g-h-n"> <td colspan="3">118 bits - constructed from interface MAC</td> </tr> <tr class="g-h-s"> <td>Name</td> <td>Size</td> <td>Description/Notes</td> </tr> <tr > <td>-</td> <td>54 bits</td> <td>all zeros</td> </tr> <tr class="g-h-n"> <td id="eui64" colspan="3">EUI-64 Contructed from the 48 bit MAC (802 LAN) or from a EUI-64 address(firewire etc.). Used both in Link-Local and SLAAC global unicast address construction</td> </tr> <tr > <td>MAC</td> <td>24 bits</td> <td>Top 24 bits of the 48 bit interface MAC. Vendor ID. Additionally, when created using the <a href="../lan/802_3_frame.htm#mac" class="t-db">MAC address</a> - or another EUI-48 derivation scheme - bit 7 (bits numbered from 1 in normal IETF convention) of this value is set to 1. Manually configured addresses do not set this bit thus both simplifying their generation and allowing external systems to identify how the address was generated. <b>Note:</b> This is the <b>reverse</b> of the meaning of this bit in the <a href="../lan/802_3_frame.htm#mac" class="t-db">MAC address</a>. </td> </tr> <tr > <td>ID</td> <td>16 bits</td> <td>Fixed value of FFFE inserted</td> </tr> <tr > <td>MAC</td> <td>24 bits</td> <td>low 24 bits of the 48 bit interface MAC. Serial number.</td> </tr> </table> <p><b>Example</b></p> <pre class="g-c-s"> # Interface MAC 00-40-63-ca-9a-20 # IPv6 Interface ID (EUI-64) # Note: bit 7 of MAC set - see notes above ::0240:63FF:FECA:9A20 # or ::240:63FF:FECA:9A20 # link local FE80::240:63FF:FECA:9A20 </pre> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="multicast">IPv6 Multicast Address Format</h2> <p>The Multicast format (which also replaces broadcast in IPv4) is defined by <a href="rfc4291.txt" class="t-db">RFC 4291 Section 2.7</a>. There is now a <a href="#local-multicast" class="t-db">link-local multicast format</a> defined by <a href="rfc4489.txt" class="t-db">RFC 4489</a>. The fomat of a global (non link-local) multicast address is defined below:</p> <p><b>Bizarre:</b> <a href="rfc4291.txt" class="t-db">RFC 4291</a> supposedly defines the IPv6 address structure including multi-cast addresses (2.7), however both <a href="rfc3306.txt" class="t-db">RFC 3306</a> and <a href="rfc3956.txt" class="t-db">RFC 3956</a> (earlier RFCs) define a more detailed format (not reflected in RFC 4291) which have been used to update the table below. Very disconcerting.</p> <table class="t-m-s"> <tr class="g-h-n"> <td class="w-80">Name</td> <td class="w-80">Bits</td> <td>Size</td> <td>Value</td> <td>Description/Notes</td> </tr> <tr > <td>Binary Prefix</td> <td>0 - 7</td> <td>8</td> <td>1111 1111</td> <td>Fixed value a.k.a the routing prefix, binary prefix</td> </tr> <tr > <td>ff1</td> <td>8-11</td> <td>4</td> <td>XRPT</td> <td>Flag field 1.<br> X flag:<br> Currently unused must be set to zero.</br> R flag: (Defined as R flag in <a href="rfc3956.txt" class="t-db">RFC 3956</a>)<br> 0 = no Rendevous Point (RP) encoded<br> 1 = RP encoded using method defined by RFC 3956. T = 1 must also be set.<br> P flag: (<a href="rfc3306.txt" class="t-db">RFC 3306</a>)<br> 0 = The multicast address is not based on the network prefix<br> 1 = the multicast address is assigned based on the network prefix (format defined in RFC 3306). T = 1 must also be set.<br> T flag:<br> 0 = "well-known" or permanently (IANA) assigned group<br> 1 = "transient" group which has no IANA assignment<br> </td> </tr> <tr > <td>scope</td> <td>12-15</td> <td>4</td> <td>-</td> <td>May take one of the following assigned values:<br> 0 - reserved<br> 1 - interface-local scope<br> 2 - link-local scope<br> 3 - reserved<br> 4 - admin-local scope<br> 5 - site-local scope<br> 6 - (unassigned)<br> 7 - (unassigned)<br> 8 - organization-local scope<br> 9 - (unassigned)<br> A - (unassigned)<br> B - (unassigned)<br> C - (unassigned)<br> D - (unassigned)<br> E - global scope<br> F - reserved</td> </tr> <tr > <td>ff2</td> <td>17 - 20</td> <td>4</td> <td>rrrr</td> <td>Flag Field 2. Values assigned by <a href="rfc7371.txt" class="t-db">RFC 7371</a>. Currently unused must be set to 0000 and ignored by receivers.</td> </tr> <tr > <td>RIID</td> <td>21 - 24</td> <td>4</td> <td>-</td> <td>RP (Rendezvous Point) Interface ID. Valid when X = 0 and R = 1 (implying that both P and T = 1) in ff1.</td> </tr> <tr > <td>plen</td> <td>25 - 32</td> <td>8</td> <td>-</td> <td>If P = 1 (in ff1 above) indicates the number of bits used in the Network Prefix field below.</td> </tr> <tr > <td>Network Prefix</td> <td>33 - 96</td> <td>64</td> <td>-</td> <td>"network prefix identifies the network prefix of the unicast subnet owning the multicast address. If P = 1, this field contains the unicast network prefix assigned to the domain owning, or allocating, the multicast address". Assumed to be a right aligned field (RFC silent on the matter), further assumed that if P = 0 field is not used (again RFC is silent on the matter).</td> </tr> <tr > <td>Group ID</td> <td>97 - 127</td> <td>32</td> <td>-</td> <td>Uniquely assigned by IANA if "well-known" bit = 0 set in T flag above. The current list of <a href="http://www.iana.org/assignments/ipv6-multicast-addresses" class="t-db">IANA IPv6 Multicast assignments</a></td> </tr> </table> <p>The following lists some of the more common multicast groups:</p> <table class="t-m-n"> <tr class="g-h-n"> <td>Address</td> <td>Description/Notes</td> </tr> <tr > <td>FF01::1</td> <td>Interface local - all nodes</td> </tr> <tr > <td>FF02::1</td> <td>Link local - all nodes</td> </tr> <tr > <td>FF01::2</td> <td>Interface local - all routers</td> </tr> <tr > <td>FF02::2</td> <td>Link local - all routers</td> </tr> </table> <p>Experiment using the <a href="#calculator" class="t-db">IPv6 Address Calculator</a>.</p> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="local-multicast">IPv6 Link Local Multicast Address Format</h2> <p>As if this stuff was not already complicated <a href="rfc4489.txt" class="t-db">RFC 4489</a> introduced the concept of a link-local (or link scoped) multicast format for situations where all configuration is stateless. Theoretically, routers (and other equipment) servicing a local (non-global) network could be now made self-configuring.</p> <table class="t-m-s"> <tr class="g-h-n"> <td class="w-80">Name</td> <td class="w-80">Bits</td> <td>Size</td> <td>Value</td> <td>Description/Notes</td> </tr> <tr > <td>Binary Prefix</td> <td>0 - 7</td> <td>8</td> <td>1111 1111</td> <td>Fixed value a.k.a the routing prefix, binary prefix</td> </tr> <tr > <td>flags</td> <td>8-11</td> <td>4</td> <td>0RPT</td> <td>Flags have same meaning as defined for <a href="#multicast" class="t-db">global multicast</a> and must be set to 0011 meaning that T = 1 = "transient" group which has no IANA assignment and R = 1 = RP (Rendevous Point) encoded using method defined by RFC 3956.</td> </tr> <tr > <td>scope</td> <td>12-15</td> <td>4</td> <td>-</td> <td>Scope has the same meaning as defined for <a href="#multicast" class="t-db">global multicast</a> but can only take the values:<br> 0 - reserved<br> 1 - interface-local scope<br> 2 - link-local scope<br> </td> </tr> <tr > <td>Reserved</td> <td>16 - 23</td> <td>8</td> <td>-</td> <td>Reserved - must be 0</td> </tr> <tr > <td>plen</td> <td>24 - 31</td> <td>8</td> <td>-</td> <td>Fixed value of 1111 1111 denotes a link-local (or link scoped) multicast address</td> </tr> <tr > <td>IID (EUI-64)</td> <td>32 - 95</td> <td>64</td> <td>-</td> <td>Assigned using the normal <a href="link-local" class="t-db">link-local</a> process depending on the media type.</td> </tr> <tr > <td>Group ID</td> <td>96 - 127</td> <td>32</td> <td>-</td> <td>Since the T bit is set this group ID is not defined by IANA though RFC 4489 does indicate that the guidelines for multicast address generation could be used (<a href="rfc3307.txt" class="t-db">RFC 4489</a> and its position within the address also implies a mask of /96 applied to both the glocal and link-local format would yield a similar result. The current list of <a href="http://www.iana.org/assignments/ipv6-multicast-addresses" class="t-db">IANA IPv6 Multicast assignments</a></td> </tr> </table> <p>Experiment using the <a href="#calculator" class="t-db">IPv6 Address Calculator</a>.</p> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="ipv6-ipv4">IPv6 - IPv4 Interworking</h2> <p>IPv6 allows transport of IPv4 addresses using two methods. The methods are described in <a href="rfc2893.txt" class="t-db">RFC 2893</a>/<a href="rfc4038.txt" class="t-db">RFC 4038</a> and <a href="rfc4291.txt" class="t-db">RFC 4291</a> Section 2.5.5.</p> <p>The first method is termed an "IPv4-compatible IPv6 address" and must use a globally unique IPv4 address. <b>Please note:</b> To avoid publication of a global IPv4 the example below shows a private (non-globally unique) IPv4 address purely to illustrate the principle:</p> <pre class="g-c-n"> # IPv4-compatible IPv6 address # assume the host has an IPv4 address of: 192.168.0.5 # this is represented by the hex value C0A80005 # the IPv4-compatible IPv6 address would be ::C0A8:5 # or if you like writing zeros 0:0:0:0:0:0:C0A8:5 # or using the hybrid IPv6 - IPv4 notation ::192.168.0.5 </pre> <p>The IPv4-compatible IPv6 address format is used when the end interface supports both IPv6 and IPv4 (a dual stack interface). <b>This method is now deprecated (RFC 4291)</b>.</p> <p>The second method is termed an "IPv4-mapped IPv6 address" and must use a globally unique IPv4 address. <b>Please note:</b> To avoid publication of a global IPv4 the example below shows a private (non-globally unique) IPv4 address purely to illustrate the principle:</p> <pre class="g-c-n"> # IPv4-mapped IPv6 address # assume the host has an IPv4 address of: 192.168.0.5 # this address is represented by the hex value C0A80005 # the IPv4-mapped IPv6 address would be ::FFFF:C0A8:5 # or if you like writing zeros 0:0:0:0:0:FFFF:C0A8:5 # or using the hybrid IPv6 - IPv4 notation ::FFFF:192.168.0.5 </pre> <p>The IPv4-mapped IPv6 address format is used when the end interface supports only IPv4 and indicates that a configured IPv6 system, for instance, a router or the IPv6 stack will have to perform conversion to the IPv4 protocol prior to communicating with the interface.</p> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="ipv6-over-ipv4">IPv6 over IPv4 Interworking</h2> <p>IPv6 over IPv4 (more commonly refered to these days as 6to4) allows two IPv6 networks/devices to communicate over an IPv4 network (defined by <a href="rfc3056.txt" class="t-db">RFC 3056</a>). Both ends of the network must have a globally unique IPv4 address and the end points must run either a 6to4 relay or a 6to4 transit service. A special unicast address block has been assigned for these classes of service (2002::/16). The IPv6 address format used by this address block is defined below <table class="t-m-s"> <tr class="g-h-n"> <td class="w-100">Name</td> <td class="w-80">Bits</td> <td>Size</td> <td>Value</td> <td>Description/Notes</td> </tr> <tr > <td>Unicast Prefix</td> <td>0 - 15</td> <td>16</td> <td>2002::/16</td> <td><a href="http://www.iana.org/assignments/ipv6-unicast-address-assignments/" class="t-db">IANA assigned value</a>.</td> </tr> <tr > <td>IPv4 Address</td> <td>16 - 47</td> <td>32</td> <td>IPv4 Global Address</td> <td>IPv4 address associated with this 6to4 relay or transit service</td> </tr> <tr > <td>subnet ID</td> <td>48 - 63</td> <td>16</td> <td>-</td> <td>Normal usage</td> </tr> <tr > <td>IID</td> <td>64 - 1273</td> <td>64</td> <td>-</td> <td>Interface ID (EUI-64)</td> </tr> </table> <p>The low order 80 bits allow for end user transparency within the IPv6 address. The relay or transit service will extract the IPv4 address when communicating accross the IPv4 cloud.</p> <p><b>Note: Another IPv4 to IPv6 transition method is biting the dust.</b> <a href="rfc7526.txt" class="t-db">RFC 7526</a> deprecates the reserved Unicast prefix (2002::/16) used in 6to4 tunneling. For backward compability the feature will still exist but for new implementations: forget it. Meh.</b> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <script type="text/javascript"> <!-- window.onerror=function(msg,url,line){ document.getElementById("ipv4zone").value = "Invalid - " + msg; return true; } function zapipv4(){ document.getElementById("ipv4addr").value = ""; document.getElementById("ipv4num").value = ""; document.getElementById("ipv4mask").value = ""; document.getElementById("ipv4range").value = ""; document.getElementById("ipv4zone").value = ""; } function zapipv4rev(){ document.getElementById("ipv4host").value = ""; document.getElementById("ipv4domain").value = ""; document.getElementById("ipv4ns1").value = ""; document.getElementById("ipv4ns2").value = ""; document.getElementById("ipv4rev").value = ""; } function zapipv4and(){ document.getElementById("ipv41").value = ""; document.getElementById("ipv42").value = ""; document.getElementById("bin1").value = ""; document.getElementById("bin2").value = ""; document.getElementById("binand").value = ""; document.getElementById("ipv4res").value = ""; } function iparray(ip,num,sep){ // create array of ip (v4 or v6) based on separator (sep) and pad with zeros if // less than num ipa = ip.split(sep); for(i = 0; i < num; i++){ //pad array with zeros if(ipa[i] == null){ ipa[i] = "0"; } } return ipa; } function ipbits(num, n){ // create contiguous 1's from left based on num, pad with 0's to n ts = ""; // init string for(i = 0; i < num;i++){ ts += "1"; } if(num < n){ for(i = 0; i < (n-num);i++){ ts += "0"; } } return ts; } function ip4dvalid(a){ // validate all elements in array // as valid ipv4 range ts = ""; for(i = 0; i < 4; i++){ tn = parseInt(a[i]); if(tn < 0 || tn > 255){ ts = "Error: IPv4 Address invalid = "+a[i]; break; } } if(a.length != 4){ ts = "Error: Too many dotted elements in IPv4 address"; } return ts; } function ipd2h(a,num){ // convert dec ip array (a) to hex string array // always with 2 chars ipa = new Array(); for(i = 0;i < num; i++){ tn = parseInt(a[i]); ts = tn.toString(16); if(ts.length == 1){ ts = "0"+ts; } ipa[i] = ts; } return ipa; } function ipd26h(a){ // convert dec ip array (a) to ipv6 hex string array // always with 4 chars (ipv4-mapped ipv6) // cringe every time you read this code ipa = new Array(); ts = "" tn = parseInt(a[0]); ta = tn.toString(16); if(ta.length == 1){ ts += "0"+ta; }else{ ts += ta; } tn = parseInt(a[1]); ta = tn.toString(16); if(ta.length == 1){ ts += "0"+ta; }else{ ts += ta; } ipa[0] = ts; ts =""; tn = parseInt(a[2]); ta = tn.toString(16); if(ta.length == 1){ ts += "0"+ta; }else{ ts += ta; } tn = parseInt(a[3]); ta = tn.toString(16); if(ta.length == 1){ ts += "0"+ta; }else{ ts += ta; } ipa[1] = ts; return ipa; } // global defs var h2b = ["0000","0001","0010","0011","0100","0101","0110","0111","1000","1001","1010","1011","1100","1101","1110","1111"]; var b2h = {'0000':"0",'0001':"1",'0010':"2",'0011':"3",'0100':"4",'0101':"5",'0110':"6",'0111':"7",'1000':"8",'1001':"9",'1010':"A",'1011':"B",'1100':"C",'1101':"D",'1110':"E",'1111':"F"}; var ipv4pres; // /prefix raw string var ipv6pres; // /prefix raw string v6 var ipv4bases; // base ipv4 raw string var ipv6bases; // base ipv6 raw string var ipv4nmda; // netmask dec array var ipv4nmha; // netmask hex array var ipv4nmbs; // netmask binary string var ipv4rlda; // range low dec array var ipv4rlha; // range low hex array var ipv4rlbs; // range low binary string var ipv4rhda; // range high dec array var ipv4rhha; // range low hex array var ipv4rhbs; // range low binary string var ipv4zones; // reverse zone origin raw string var ipv6zone; // reverse v6 zone origin raw string var ipv4revn; // reverse zone num of elements var ipv6revn; // reverse v6 zone num of elements var ipv4num; // number of ips var ipv6num; // number of v6 ips var ipv4masks; // ipv4 netmask var ipv6userbs; // user base binary function iph2b(a,z){ // convert an array (a) of hex octets to a binary string // z = no of octets in entry ts = ""; for(i = 0; i < a.length; i++){ s = a[i]; n = parseInt(s[0],16); ts += h2b[n]; n = parseInt(s[1],16); ts += h2b[n]; if(z == 2){ n = parseInt(s[2],16); ts += h2b[n]; n = parseInt(s[3],16); ts += h2b[n]; } } return ts; } function ipand(m,n){ // bit wise ANDs two strings and returns result ts = ""; for(i = 0;i < m.length; i++){ if(m[i] == "1" && n[i] == "1"){ ts += "1"; }else{ ts += "0"; } } return ts; } function ipb2h(bs,num,s){ // convert bs to hex array // with num elements of size s (8 or 16 bits) ipa = new Array(); for(i = 0,k=0;i < num;i++,k = k+s){ ts = ""; tb = bs.substr(k,4); ts+= b2h[tb][0]; tb = bs.substr((k+4),4); ts+= b2h[tb][0]; if(s == 16){ tb = bs.substr(k+8,4); ts+= b2h[tb][0]; tb = bs.substr((k+12),4); ts+= b2h[tb][0]; } ipa[i] = ts; } return ipa; } function iph2d(ha){ // convert hex array to decimal ipa = new Array(); for(i =0;i < ha.length;i++){ tn = parseInt(ha[i],16); ipa[i] = tn.toString(); } return ipa; } function ipa2p(a,sep){ // convert array to printable with sep between elements ts = ""; for(i = 0;i < a.length; i++){ if(i != 0){ ts += sep; } ts += a[i]; } return ts; } function ipa2pr(a,sep,c,d){ // convert array to printable in reverse with sep between elements // c defines number of entries required from right (end) // d = 0 all entries, d = 1 only last entry ts = ""; k = parseInt(c); for(i = (a.length - 1);i >= k; i--){ if(d == 1 && i == k){ ts += a[i]; }else if(d == 0){ ts += a[i]; if(i != k){ // no dot for last ts += sep; } } } return ts; } function ipa2pr6(h,sep,c){ // convert array to printable in reverse with sep between elements // if c = 0 = all, else defines number of entries required from end var y = ipa2p(h,""); // dense string var ts = ""; for(i = 31; i >= c;i--){ ts += y[i]; if(i != c){ ts += "." } } return ts; } function ipinv(bs){ // invert binary string ts = ""; for(i = 0;i < bs.length;i++){ if(bs[i] == "1"){ ts += "0"; }else{ ts += "1"; } } return ts; } function ipor(m,n){ // OR binary string ts =""; for(i = 0;i < m.length;i++){ if(m[i] == "1" || n[i] == "1"){ ts += "1"; }else{ ts += "0"; } } return ts; } function bininc(s,n){ // increment binary string by 1 // in nth octet (base 0) ts = s; o = (n * 8) + 8; // offset of last element in octet arl = s.length - o; for(i = o -1, k = arl; i > 0; i--, k++){ if(s[i] == "0"){ ts = s.substr(0,i); ts += "1"; for(j = 0;j < k;j++){ // zero to right ts+= "0"; } break; } } return ts; } function doipv4(){ var ipv4 = document.getElementById("ipv4addr").value; ipv4num = document.getElementById("ipv4num").value; document.getElementById("ipv4mask").value = ""; document.getElementById("ipv4range").value = ""; document.getElementById("ipv4zone").value = ""; ipv4mask = ""; n = ipv4.indexOf("/"); if(n < 0){ // calculate /prefix (but check...) if(ipv4num == ""){ ipv4mask = "Single IPv4 without No. of IPs not supported"; }else{ // calculate prefix from no. of ips p = 1; n = parseInt(ipv4num); i = 0; while (p < n){ // nearest rounded up ^ 2 p*=2; i++; } ipv4pres = 32-i; // /prefix ipv4bases = ipv4; document.getElementById("ipv4addr").value = ipv4bases+"/"+ipv4pres; } }else{ // with /prefix ipv4pres = ipv4.substr(n + 1,ipv4.length - (n + 1)); ipv4bases = ipv4.substr(0,n); // validate prefix rn = parseInt(ipv4pres) if(rn > 32 || rn < 1){ ipv4mask = "Error: /Prefix not in range 1 to 32"; } } if(ipv4mask == ""){ // stop for errors // ipv4bases = an IP in range, ipv4pres = /prefix in all cases // convert ipv4 to a 4 entry decimal and hex array ipv4da = iparray(ipv4bases,4, "."); if((ipv4mask = ip4dvalid(ipv4da)) == ""){ ipv4ha = ipd2h(ipv4da,4); ipv4bs = iph2b(ipv4ha,1); ipv4nmbs = ipbits(ipv4pres,32); // netmask as binary string ipv4rlbs = ipand(ipv4bs, ipv4nmbs); // bit wise and to get low range ip ipv4rlha = ipb2h(ipv4rlbs,4,8); ipv4rlda = iph2d(ipv4rlha); // range ipv4range = ipa2p(ipv4rlda,"."); ipv4range += " ["+ipa2p(ipv4rlha,".")+"]"; // calculate max of range (or reverse bit map) ipim = ipinv(ipv4nmbs); ipv4rhbs = ipor(ipv4rlbs,ipim); ipv4rhha = ipb2h(ipv4rhbs,4,8); ipv4rhda = iph2d(ipv4rhha); ipv4range += " - "+ipa2p(ipv4rhda,"."); ipv4range += " ["+ipa2p(ipv4rhha,".")+"]"; // netmask ipv4nmha = ipb2h(ipv4nmbs,4,8); ipv4nmda = iph2d(ipv4nmha); ipv4mask = ipa2p(ipv4nmda,"."); ipv4masks = ipv4mask; ipv4mask += " ["+ipa2p(ipv4nmha,".")+"]"; // reverse zone ipv4zone = ""; // calculate valid reverse elements based on /prefix ipv4revn = Math.floor(ipv4pres / 8); for(i = ipv4revn -1; i >= 0;i--){ ipv4zone+= ipv4rlda[i]+"."; } ipv4zone += "in-addr.arpa."; ipv4zones = ipv4zone; // populate form document.getElementById("ipv4range").value = ipv4range; document.getElementById("ipv4zone").value = ipv4zone; // number of ips ipv4num = (Math.pow(2,(32-parseInt(ipv4pres))).toString()); document.getElementById("ipv4num").value = ipv4num; } } document.getElementById("ipv4mask").value = ipv4mask; // for errors } function doipv4and(){ var ipv41 = document.getElementById("ipv41").value; var ipv42 = document.getElementById("ipv42").value; document.getElementById("bin1").value = ""; document.getElementById("bin2").value = ""; document.getElementById("binand").value = ""; var ipv4res = ""; if(ipv41 == "" && ipv4bases == ""){ ipv4res = "Error: IPv4 1 not defined"; }else if (ipv42 =="" && ipv4masks == ""){ ipv4res = "Error: IPv4 2 not defined"; }else{ if(ipv41 == ""){ ipv41 = ipv4bases; document.getElementById("ipv41").value = ipv41; } if(ipv42 == ""){ ipv42 = ipv4masks; document.getElementById("ipv42").value = ipv42; } ip41da = iparray(ipv41,4,"."); if((ipv4res = ip4dvalid(ip41da)) == ""){ ip42da = iparray(ipv42,4,"."); if((ipv4res = ip4dvalid(ip42da)) == ""){ ip41ha = ipd2h(ip41da,4); bin1 = iph2b(ip41ha,1); ip42ha = ipd2h(ip42da,4); bin2 = iph2b(ip42ha,1); binand = ipand(bin1,bin2); ipresha = ipb2h(binand,4,8); ipresda = iph2d(ipresha); ipv4res = ipa2p(ipresda,"."); document.getElementById("bin1").value = bin1; document.getElementById("bin2").value = bin2; document.getElementById("binand").value = binand; } } } document.getElementById("ipv4res").value = ipv4res; } function fqdn(d,sub){ // validate that domain name has trailing dot, else add ts = d; if(ts != ""){ if(d[d.length-1] != "."){ if(sub != ""){ ts += "."+sub; }else{ ts += "."; } } } return ts; } function doipv4rev(){ var ipv4 = document.getElementById("ipv4addr").value; var ipv4host = document.getElementById("ipv4host").value; var ipv4domain = document.getElementById("ipv4domain").value; var ipv4ns1 = document.getElementById("ipv4ns1").value; var ipv4ns2 = document.getElementById("ipv4ns2").value; var ipv4dg = document.getElementById("ipv4dg").checked; var ipv4ptr = document.getElementById("ipv4ptr").value; var ipv4dash = document.getElementById("ipv4dash").checked; document.getElementById("ipv4rev").value = ""; document.getElementById("ipv4rrs").value = ""; ipv4rev = ""; ipv4rrs = ""; if(ipv4 == ""){ ipv4rev = "Error: No IPv4/Prefix present"; }else if(ipv4host == "" || ipv4domain == "" || ipv4ns1 == ""){ ipv4rev = "Error: One or more of Host Label, Domain Label or NS1 are missing"; }else{ doipv4(); //always do this in case user has changed something tnm = document.getElementById("ipv4mask").value; tr = document.getElementById("ipv4zone").value; if(tnm != "" && tr == ""){ ipv4rev = "Error: in IPV4/Prefix check and correct"; }else{ // check size of file if(ipv4num > 4096 && ipv4dg == false){ var r = confirm("This will generate "+ipv4num+" PTR entries. This is a BIG file. Do you want to proceed?"); if(r == false){ ipv4rev = "Cancelled by user"; } } if(ipv4rev == ""){ // fix FQDN's if required ipv4domain = fqdn(ipv4domain,""); ipv4ns1 = fqdn(ipv4ns1,ipv4domain); ipv4ns2 = fqdn(ipv4ns2,ipv4domain); ipv4ptr = fqdn(ipv4ptr,""); ptrlabel = ipv4domain; if(ipv4ptr != ""){ ptrlabel = ipv4ptr; } // let's generate a zone file ipt = ipv4rlbs; if(ipv4dg == true){ // fix zone iptha = ipb2h(ipt,4,8); iptda = iph2d(iptha); iptp = ipa2pr(iptda, ".",ipv4revn,1); ipv4zoneorg = ipv4zones; // save original ipv4delstub = "/"+ipv4pres; if(ipv4dash == true){ ipv4delstub = "-"+ipv4pres; } ipv4delorg = iptp+ipv4delstub; ipv4zones = ipv4delorg+"."+ipv4zones; } if(!(ipv4dg == true && ipv4pres < 24)){ ipv4rev = "; start of "+ipv4zones+" reverse zone file \n"; if(ipv4dg == true){ ipv4rev += "; delegated reverse zone file\n"; } ipv4rev += "$TTL 172800 ; default TTL = two days\n"; ipv4rev += "$ORIGIN "+ipv4zones+"\n"; ipv4rev += "@\tSOA "+ipv4ns1+" hostmaster."+ipv4domain+" 1 172800 900 1209600 3600\n"; ipv4rev += "\tNS "+ipv4ns1+"\n"; if(ipv4ns2 != ""){ ipv4rev += "\tNS "+ipv4ns2+"\n"; } // loop to generate ptrs rn = parseInt(ipv4num) + 1; for(x = 1; x < rn; x++){ iptha = ipb2h(ipt,4,8); iptda = iph2d(iptha); iptp = ipa2pr(iptda, ".",ipv4revn,0); ipv4rev += iptp+"\tPTR "+ipv4host+x+"."+ptrlabel+"\n"; ipt = bininc(ipt,3); // add one to binary address } ipv4rev += "; end of zone file"; } if(ipv4dg == true){ // gnerate Delegation RRs ipt = ipv4rlbs; // reset base ipv4rrs += "; RRs for ISP or delegater's reverse map zone\n"; ipv4rrs += "; zone = $ORIGIN "+ipv4zoneorg+"\n"; rr = "CNAME"; if(ipv4pres < 24){ rr = "DNAME"; pren = parseInt(ipv4pres); block = Math.floor(pren /8); // multiple of 8 (IPv4 delegation unit) delpre = block * 8; // /prefix for delegation base delmask = ipbits(delpre,32); // create netmask ipt = ipand(ipv4rlbs,delmask); // base IP bit string for delegation raise = pren - delpre; // bits in delegation unit outer = Math.pow(2,raise); // no of delegations inner = 256 / outer; // no. of items in delegation dd = "0"+ipv4delstub; ipv4rrs += "; no of blocks = "+outer+" IPs per block = "+inner+" (in this file)\n"; ipv4rrs += "; IPs in each reverse zone file = "+ipv4num+"\n"; for(x = 0; x < outer; x++){ ipv4rrs += "; start of block "+x+" ("+dd+")\n" for(z = 0; z < inner; z++){ iptha = ipb2h(ipt,4,8); iptda = iph2d(iptha); iptp = ipa2pr(iptda, ".",ipv4revn,1); ipv4rrs += iptp+"\t"+rr+" "+iptp+"."+dd+"\n"; ipt = bininc(ipt, block); // add one to binary address } // change dd ipv4rrs += "; end of block "+x+" ("+dd+")\n" iptha = ipb2h(ipt,4,8); iptda = iph2d(iptha); iptp = ipa2pr(iptda, ".",ipv4revn,1); dd = iptp+ipv4delstub; } }else{ // generate simple CNAME delegation RRs for(x = 1; x < rn; x++){ iptha = ipb2h(ipt,4,8); iptda = iph2d(iptha); iptp = ipa2pr(iptda, ".",ipv4revn,0); ipv4rrs += iptp+"\t"+rr+" "+iptp+"."+ipv4delorg+"\n"; ipt = bininc(ipt,3); // add one to binary address } } ipv4rrs += "; end of reverse delegation RRs"; document.getElementById("ipv4rrs").value = ipv4rrs; } } } } document.getElementById("ipv4rev").value = ipv4rev; } function ip62h(s){ // created an 8 element array with full // expansion to 4 char valid hex element // if ok returns array else string with error // now supports x:x:x:x:x:x:d.d.d.d format a = s.split(":"); if(a.length > 8){ a = "Error: too many IPv6 elements"; }else{ n = 0; // fix terminal condition when :: appears at end if(a[a.length-1] == ""){ a.pop(); }else{ // mutually exclusive condition d = a[a.length-1].split("."); // ipv4-mapped if(d.length > 1){ ts = a.pop(); tda = iparray(ts,4,"."); if((ts = ip4dvalid(tda)) == ""){ tha = ipd26h(tda); a.push(tha[0]); a.push(tha[1]); }else{ a = ts; } } } if(typeof a != "string"){ // check last element for dotted decimal for(i = 0;i < a.length; i++){ // check element for length, pad with zeros, valid hex if(a[i] != ""){ // skip empty elements just now if(a[i].length > 4){ a = "Error: IPv6 element too big"; break; }else{ a[i] = a[i].toLowerCase(); // minimise range ts = a[i]; for(k = 0; k < ts.length; k++){ if(ts[k] < "0" || ts[k] > "f"){ a = "Error: IPv6 must be in range 0 - 9, a - f"; break; }else if(ts[k] > "9" && ts[k] < "a"){ a = "Error: IPv6 must be in range 0 - 9, a - f"; break; } } switch(a[i].length){ case 1: a[i] = "000"+a[i]; break; case 2: a[i] = "00"+a[i]; break; case 3: a[i] = "0"+a[i]; break; default: // = 4 } } }else{ if((++n) > 1){ a = "Error: IPv6 Double zero elimination (::) in address not allowed" break; } } } if(typeof a != "string"){ // fix array size to 8 - fix :: n = (8 - a.length) + 1; // replace the empty one! b = new Array(); for(i = 0;i < a.length;i++){ if(a[i] == ""){ for(k = 0; k < n; k++){ b.push("0000"); } }else{ b.push(a[i]); } } return b; } } } return a; } function ipv6comp(h){ // compress hex ipv6 array // remove any leading zeros, compress longest 0 block // double pass 1 = leading zeros & count zero blocks // 2 eliminate largest zero block and single zero to others ts = ""; ta = new Array(); as = h.length; n = 0; // zero block count; hc = 0; // highest contiguous zero cells hi = 0; // highest index // pass 1 for(i = 0; i < as; i++){ if(h[i] == "0000"){ if ((++n) > hc){ hc = n; hi = i; } ta[i] = "0"; }else{ n = 0; td = h[i]; for(k = 0; k < 4; k++){ if(td[k] != "0"){ break; } } ta[i] = td.substr(k, 4 - k); } } // pass 2 li = (hi - hc) + 1; // lowest cell in elimination for (i = 0; i < as; i++){ if(i == li){ ts += ":"; } if(i >= li && i < hi){ }else if(i == hi && i == (as -1)){ ts += ":"; }else if (i == hi){ }else{ if(i != 0){ ts += ":"; } ts += ta[i]; } } return ts; } function zapipv6(){ document.getElementById("ipv6addr").value = ""; document.getElementById("ipv6exp").value = ""; document.getElementById("ipv6num").value = ""; document.getElementById("ipv6mask").value = ""; document.getElementById("ipv6grp").value = ""; document.getElementById("ipv6user").value = ""; document.getElementById("ipv6zone").value = ""; document.getElementById("ipv6inzone").value = ""; } function zapipv6rev(){ document.getElementById("ipv6host").value = ""; document.getElementById("ipv6domain").value = ""; document.getElementById("ipv6ns1").value = ""; document.getElementById("ipv6ns2").value = ""; document.getElementById("ipv6rev").value = ""; } function doipv6(){ var ipv6 = document.getElementById("ipv6addr").value; ipv6num = document.getElementById("ipv6num").value; document.getElementById("ipv6exp").value = ""; document.getElementById("ipv6grp").value = ""; document.getElementById("ipv6user").value = ""; document.getElementById("ipv6zone").value = ""; document.getElementById("ipv6inzone").value = ""; var ipv6mask = ""; n = ipv6.indexOf("/"); if(n < 0){ // calculate /prefix (but check...) if(ipv6num == ""){ ipv6mask = "Error: Single IPv6 without No. of IPs not supported"; }else if(ipv6num.length > 6){ ipv6mask = "Error: No of IPs too big"; }else{ // calculate prefix from no. of ips p = 1; n = parseInt(ipv6num); i = 0; while (p < n){ // nearest rounded up ^ 2 p*=2; i++; } ipv6pres = 128-i; // /prefix ipv6bases = ipv6; document.getElementById("ipv6addr").value = ipv6bases+"/"+ipv6pres; } }else{ // with /prefix ipv6pres = ipv6.substr(n + 1,ipv6.length - (n + 1)); ipv6bases = ipv6.substr(0,n); // validate prefix rn = parseInt(ipv6pres) if(rn > 128 || rn < 4){ ipv6mask = "Error: /Prefix not in range 4 to 128"; }else{ if((rr = rn % 4) != 0){ ipv6mask = "Error: /Prefix not multiple of 4"; } } } if(ipv6mask == ""){ // stop for errors // ipv6bases = an IP in range, ipv6pres = /prefix in all cases // convert ipv6 to a 8 entry decimal and hex array if(typeof (ipv6ha = ip62h(ipv6bases)) == "string"){ ipv6mask = ipv6ha; // error msg }else{ ipv6exp = ipa2p(ipv6ha,":"); ipv6nmbs = ipbits(ipv6pres,128); ipv6nmha = ipb2h(ipv6nmbs,8,16); ipv6mask = ipv6comp(ipv6nmha); ipv6bs = iph2b(ipv6ha,2); ipv6grpbs = ipand(ipv6bs, ipv6nmbs); ipv6grpha = ipb2h(ipv6grpbs,8,16); ipv6grp = ipv6comp(ipv6grpha); iptbs = ipinv(ipv6nmbs); ipv6userbs = ipand(ipv6bs,iptbs); ipv6userha = ipb2h(ipv6userbs,8,16); ipv6user = ipv6comp(ipv6userha); // reverse map based on /prefix ipv6revn = Math.floor(ipv6pres / 4); ipt = ipa2p(ipv6ha,""); ipv6zone = ""; for(i = ipv6revn -1; i >= 0;i--){ ipv6zone+= ipt[i]+"."; } ipv6zone += "ip6.arpa."; ipv6inzone = ""; for(i = 31; i >= ipv6revn;i--){ ipv6inzone+= ipt[i]+"."; } ipv6inzone = ipv6inzone.substr(0,ipv6inzone.length -1); tn = 128 - parseInt(ipv6pres); if(tn > 20){ ipv6num = "A lot"; }else{ ipv6num = (Math.pow(2,tn).toString()); } document.getElementById("ipv6num").value = ipv6num; document.getElementById("ipv6inzone").value = ipv6inzone; document.getElementById("ipv6exp").value = ipv6exp; document.getElementById("ipv6grp").value = ipv6grp; document.getElementById("ipv6user").value = ipv6user; document.getElementById("ipv6zone").value = ipv6zone; } } document.getElementById("ipv6mask").value = ipv6mask; // for errors } function doipv6rev(){ var ipv6 = document.getElementById("ipv6addr").value; var ipv6host = document.getElementById("ipv6host").value; var ipv6domain = document.getElementById("ipv6domain").value; var ipv6ns1 = document.getElementById("ipv6ns1").value; var ipv6ns2 = document.getElementById("ipv6ns2").value; var ipv6start = document.getElementById("ipv6start").value; var ipv6sn = 0; ipv6rev = ""; if(ipv6 == ""){ ipv6rev = "Error: No IPv6/Prefix present"; }else if(ipv6host == "" || ipv6domain == "" || ipv6ns1 == ""){ ipv6rev = "Error: One or more of Host Label, Domain Label or NS1 are missing"; }else{ doipv6(); //always do this in case user has changed something tnm = document.getElementById("ipv6mask").value; tr = document.getElementById("ipv6zone").value; if(tnm != "" && tr == ""){ ipv4rev = "Error: in IPV6/Prefix check and correct"; }else{ if(ipv6start != 0){ if(ipv6start.length > 6){ ipv6rev = "Error: Host Start too long"; }else{ ipv6sn = parseInt(ipv6start); } }else{ // check size of file if(ipv6num =="A lot"){ alert("Reverse file too big to safely generate in your browser"); ipv6rev = "Cancelled by calculator"; }else if(ipv6num > 4096){ var r = confirm("This will generate "+ipv6num+" PTR entries. This is a BIG file. Do you want to proceed?"); if(r == false){ ipv6rev = "Cancelled by user"; } } } if(ipv6rev == ""){ // fix FQDN's if required ipv6domain = fqdn(ipv6domain,""); ipv6ns1 = fqdn(ipv6ns1,ipv6domain); ipv6ns2 = fqdn(ipv6ns2,ipv6domain); // let's generate a zone file ipv6rev = "; start of "+ipv6zone+" reverse zone file \n"; ipv6rev += "$TTL 172800 ; default TTL = two days\n"; ipv6rev += "$ORIGIN "+ipv6zone+"\n"; ipv6rev += "@\tSOA "+ipv6ns1+" hostmaster."+ipv6domain+" 1 172800 900 1209600 3600\n"; ipv6rev += "\tNS "+ipv6ns1+"\n"; if(ipv6ns2 != ""){ ipv6rev += "\tNS "+ipv6ns2+"\n"; } // loop to generate ptrs ipt = ipv6userbs; rn = parseInt(ipv6num) + 1; for(x = 1; x < rn; x++){ iptha = ipb2h(ipt,8,16); iptp = ipa2pr6(iptha, ".",ipv6revn); ipv6rev += iptp+"\tPTR "+ipv6host+ipv6sn+"."+ipv6domain+"\n"; ipt = bininc(ipt,15); // add one to binary address ipv6sn++; } ipv6rev += "; end of zone file"; } } } document.getElementById("ipv6rev").value = ipv6rev; } //--> </script> <h2 id="calculator">IPv6 Address Calculator</h2> <p><b>IPv6 Calculator:</b> Enter an IPv6 address with its /Prefix (or slash) notation in the <b>IPv6/Prefix:</b> box and click <b>IPv6 Info</b>. The calculator will fully expand the IPv6 address and place in <b>IPv6 Expanded:</b>, <b>IPv6 Netmask</b> in compressed format, <b>IPv6 GPR</b> contains the top part or the address which may be the Global Routing Prefix (GRP) or not depending on the /Prefix value and <b>IPv6 User:</b> is the lower part of the address based on the /Prefix value. Finally, the reverse map zone name of the IPv6 address is calculated based on the /Prefix value (IPv6 addresses below this name will be defined in the reverse zone file) and shown in FQDN format in <b>Reverse Zone</b>. <b>In Zone IPv6:</b> shows the IPv6 address element that would appear with the zone file based on the /Prefix value. Since IPv6 addresses cover very serious numbers the <b>No. of IPs:</b> box is only used in the alternative mode described below and is only updated in that context.</p> <p>Alternatively, enter a single IPv6 address (that lies anywhere in the desired range) without the /prefix in <b>IPv6/Prefix</b> and the number of desired IP addresses (if it is not a power of 2 it will be rounded up to the nearest power of 2 - a maximum of 6 digits is allowed) in <b>No. of IPs</b> then click <b>IPv6 Info</b>. The calculator will populate <b>IPv6/Prefix</b> (with the calculated /Prefix to cover the required or calculated number of IP addresses), <b>No. of IPs</b> will be updated if needed (due to any power of 2 rounding required) and <b>IPv6 Netmask</b>, <b>IPv6 GPR</b>, <b>IPv6 User:</b>, <b>Reverse Zone</b> and <b>In Zone IPv6:</b> will be populated normally.</p> <p>The <b>Clear</b> button zaps ALL entries in IPv6 Calculator only.</p> <p><b>Notes:</b></p> <ol> <li><p>Validation and other errors are shown in the <b>IPv6 Netmask</b> box for no very good reason.</p></li> <li><p>When entering a /prefix IPv6 address you only need to enter as many colon elements as are required by the /prefix (more is not a problem), if you enter less than the required number the calculator silently pads to the right with zeros.</p></li> <li><p>While a /Prefix for IPv6 is most normally a multiple of 8 (or even 16) the calculator allows any bit value. You can break on very strange boundaries if desired.</p></li> <li><p>The calculator follows the recommendation of <a href="rfc5952.txt" class="t-db">RFC 5952</a> about use of lower case hexadecimal characters, removal of all leading zeros in address elements, largest zero block elimination but it will eliminate a single zero block if this is the only one available (since this obeys the longest zero block elimination rule).</p></li> <li><p>The calculator accepts IPv6 addresses in IPv4-Mapped IPv6 format (x:x:x:x:x:x:d.d.d.d) but does not verify that the required selectors are present. You currently have to do some work.</p></li> </ol> <table class="p-m-s t-t-l"> <tr> <td class="w-120"><b>IPv6/Prefix:</b></td> <td><input type="text" id="ipv6addr" size="30"></td> <td class="w-80"><b>No. of IPs:</b></td> <td><input type="text" id="ipv6num" size="10"></td> </tr> <tr> <td><b>IPv6 Expanded:</b></td> <td colspan="3"><input type="text" id="ipv6exp" size="50"></td> </tr> <tr> <td><b>IPv6 Netmask:</b></td> <td colspan="3"><input type="text" id="ipv6mask" size="50"></td> </tr> <tr> <td><b>IPv6 GPR:</b></td> <td colspan="3"><input type="text" id="ipv6grp" size="50"></td> </tr> <tr> <td><b>IPv6 User:</b></td> <td colspan="3"><input type="text" id="ipv6user" size="50"></td> </tr> <tr> <td><b>Reverse zone:</b></td> <td colspan="3"><input type="text" id="ipv6zone" size="50"></td> </tr> <tr> <td><b>In Zone IPv6:</b></td> <td colspan="3"><input type="text" id="ipv6inzone" size="50"></td> </tr> <tr> <td> </td> <td colspan="3"><input type="button" value="Clear" onclick="zapipv6();"> <input type="button" value="IPv6 Info" onclick="doipv6();"></td> </tr> </table> <p><b>Notes:</b></p> <ol> <li><p>Javascript implementations may vary from browser to browser. This feature was tested with MSIE 10, Gecko (Firefox 25.0.1), Opera 11.10 and Chrome (31.0.1650.57 m) - so will likely work with any WebKit based browser, which obviously includes Safari (and now even Opera!)). If the tester does not work for you we are very, very sad - but yell at your browser supplier not us. However, if you do think you have found, or want to suggest improvements, an error please take the time to email using the link at the foot of this page.</p></li> </ol> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="frame">IPv6 Frame Format</h2> <p>IPv6 headers are daisy chained. The <b>Next Header</b> field - present in every header except the upper layer header - indicates which header comes next as shown in the diagram below:</p> <img class="center" src="../../images/ipv6_headers.gif" alt="IPv6 Daisy chained headers"> <p><b>Notes:</b></p> <ol> <li><p>Zero or more Extension headers may be present.</p></li> <li><p>Multiple Extension headers of any type may be present.</p></li> <li><p>All Extension headers are assumed to be of variable length and contain a length value (expressed in multiples of 8 octets).</p></li> <li><p>Only one upper layer header may be present and is unchanged from IPv4 e.g. <a href="tcp.html#tcp" class="t-db">tcp</a> with the exception of the format of the 'pseudo-header' used to generate the checksum.</p></li> <li><p>Data (MTU) length is defined to be a minimum of 1280 octets with a recommendation of 1500+ octets. If any routing link cannot carry this size of MTU, link specific fragmentation must be carried out below (i.e. invisible to) IPv6.</p></li> <li><p>When carrying UDP traffic in the upper layers the optional (in IPv4) UDP checksum MUST be present.</p></li> <li><p>The pseudo header used in TCP, UDP and IPv6 ICMP is assumed be a 40 octet field and have the following format: <table class="t-m-s"> <tr class="g-h-s"> <td class="w-100">Name</td> <td class="w-50">Size</td> <td>Description/Notes</td> </tr> <tr > <td>Source</td> <td>128 bits</td> <td>IPv6 source address</td> </tr> <tr > <td>Destination</td> <td>128 bits</td> <td>IPv6 destination address</td> </tr> <tr > <td>Packet Length</td> <td>32 bits</td> <td>Length in octets of the upper layer data packet plus associated header.</td> </tr> <tr > <td>-</td> <td>24 bits</td> <td>Must be zeros</td> </tr> <tr > <td>Next Header</td> <td>8 bits</td> <td>Assumed to contain the value of the protocol carried in the upper layer e.g. 6 = TCP etc..</td> </tr> </table> </li> </ol> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="header">IPv6 Header Format</h2> <table class="t-m-s"> <tr class="g-h-n"> <td colspan="3">IPv6 Header Format</td> </tr> <tr class="g-h-s"> <td class="w-100">Name</td> <td>Length</td> <td>Description/Notes</td> </tr> <tr > <td>version</td> <td>4 bits</td> <td>value = 6. Same location as IPv4 - everything after this changes.</td> </tr> <tr > <td>traffic class</td> <td>8 bits</td> <td>None formally defined with IANA (late 2004). When used with Explicit Congestion Notification (ECN) (RFC 3168) may take values defined <a href="http://www.iana.org/assignments/ipv4-tos-byte" class="t-db">here</a> and <a href="http://www.iana.org/assignments/dscp-registry" class="t-db">here</a>.</td> </tr> <tr > <td>Flow Label</td> <td>20 bits</td> <td>-</td> </tr> <tr > <td>payload length</td> <td>16 bits</td> <td>unsigned length in octets of payload (excludes header but includes extensions)</td> </tr> <tr > <td>next header</td> <td>8 bits</td> <td id="protocol">Identifier in following header - same values as <a href="tcp.html#protocol" class="t-db">IPv4 Protocol field</a> Some common values:<br> 0 (0x00) <a href="#hop" class="t-db">IPv6 Hop-by-Hop Option</a><br> 1 (0x01) <a href="tcp.html#icmp" class="t-db">ICMP protocol</a><br> 2 (0x02) IGMP protocol<br> 4 (0x04) IP over IP<br> 6 (0x06) <a href="tcp.html#tcp" class="t-db">TCP protocol</a><br> 17 (0x11) <a href="tcp.html#udp" class="t-db">UDP protocol</a><br> 41 (0x29) <a href="#ipv6" class="t-db">IPv6 protocol</a><br> 58 (0x3A) <a href="#icmp" class="t-db">IPv6 ICMP protocol</a><br> 59 (0x3B) <a href="#icmp" class="t-db">IPv6 No Next Header (terminates a no upper layer frame)</a><br> <a href="http://www.iana.org/assignments/protocol-numbers" class="t-db">Definitive list is here</a></td> </tr> <tr > <td>hop limit</td> <td>8 bits</td> <td>Maximum number of hops. Formalises the current practice when using the <a href="tcp.html#ttlf" class="t-db">TTL</a> in IPv4.</td> </tr> <tr > <td>source IP</td> <td>128 bits</td> <td>-</td> </tr> <tr > <td>destination IP</td> <td>128 bits</td> <td>-</td> </tr> </table> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="order">Order of Headers</h2> <p>Where multiple headers are present the recommended sender order is (but the receiver must accept in any order):</p> <blockquote> IPv6 Header<br> Hop-by-Hop Header<br> Destination Options<br> Routing Headers<br> Fragment Headers<br> Authentication Headers<br> Encapsulation Security Payload (ESP) Header<br> Destination Options<br> Upper Layer Header + data </blockquote> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="extension">Extension Headers</h2> <p>Extension headers are always multiples of 8 octets. To allow skipping and processing of extension headers they all begin with the following 16 bit stub format:</p> <table class="t-m-s"> <tr class="g-h-n"> <td colspan="3">IPv6 Extension Header - Stub format</td> </tr> <tr class="g-h-s"> <td class="w-120">Name</td> <td>Length</td> <td>Description/Notes</td> </tr> <tr > <td>Next Header</td> <td>8 bits</td> <td>Same values as <a href="#protocol" class="t-db">IPv6 Next Header</a></td> </tr> <tr > <td>Extension Hdr Len</td> <td>8 bits</td> <td>Unsigned integer. The total length of the extension header in multiples of 8 octets, <b>excluding</b> the first 8 octets e.g. a value of 0 = 8 octet header length, value = 2 = 24 octet header length etc. <b>NB</b> the length field in ICMPv6 does <b>not</b> use this convention - it's always good to have consistency in standards.</td> </tr> </table> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h3 id="ipv6-padding">Header Options</h3> <p>The Hop-By-Hop and Destination Headers carry a variable number of options within the header and use a classic TLD (or TLV in the standards paralance) format as shown below:</p> <table class="t-m-s"> <tr class="g-h-n"> <td class="w-80">Name</td> <td>Length</td> <td>Description/Notes</td> </tr> <tr > <td>Type</td> <td>8 bits</td> <td>The two high order (or low order depending on your numbering convention) bits indicate what action to take if the option is not recognized and may take one of the following values: 00 = skip option - keep processing<br> 01 = discard packet<br> 10 = discard packet and send ICMPv6 <a href="ipv6-formats.html#icmpv6-error-parameter" class="t-db">Parameter Problem (Code 2)</a> message<br> 11 = discard packet and, if not Multicast address, send ICMPv6 <a href="ipv6-formats.html#icmpv6-error-parameter" class="t-db">Parameter Problem (Code 2)</a> message<br> The third high order bit indicates whether the option can change before reaching its destination 0 = data will not change, 1 = data may change. If the bit is set and an Authentication Header is present then an all zero option value must be assumed when computing any digest. </td> </tr> <tr > <td>Length</td> <td>8 bits</td> <td>Length in octets of the option data - does <b>not</b> include the type or length value.</td> </tr> <tr > <td>Data</td> <td>variable</td> <td>Depends on Type</td> </table> <p>In order to force so-called natural alignment of option fields two padding options are provided. An Option Type of 0 indicates a 1 octet pad (and does not have associated length or data fields), a standard Option with a Type of 1 allows for multiple octet padding. <b>NB</b> in this case a 2 octet pad will have an Option Length of 0.</p> <h2 id="ipv6-hop-by-hop">IPv6 Hop-By-Hop Header</h2> <p>One Day Real Soon Now ™</p> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="ipv6-destination">IPv6 Destination Header</h2> <p>One Day Real Soon Now ™</p> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <h2 id="rfcs">IPv6 RFCs</h2> <p>This rather daunting list of RFCs describe IPv6 or are relevant to it. Many of the later RFCs simply roll-back features of the earlier ones. Most of the new work is associated with mobile development and various tunneling methods.</p> <p><b>Note:</b> The main repository for RFCs is <a href="https://www.ietf.org/standards/rfcs" class="t-db"> maintained by the IETF</a>, text versions (the normative reference, but PDF and HTML versions are also available) may be viewed at <b>www.ietf.org/rfc/rfcXXXX.txt</b> or <b>www.rfc-editor.org/rfc/rfcXXXX.txt</b> (where XXXX is the 4 digit RFC number - left padded with zeros as necessary). Currently published RFCs are pointed to <b>https://www.rfc-editor.org/info/rfcXXXX</b> which contains various information and links to the text (normative) reference and PDF and HTML (non-normative) version. The RFC may also be viewed at <b>http://datatracker.ietf.org/doc/rfcXXXX/</b> which also contains various RFC status information including errata together with a list of alternative formats, such as, text, PDF and HTML (this is the working area version of the document). Finally, there is now <a href="https://datatracker.ietf.org/doc/" class="t-db">a searchable RFC list</a>.</p> <p><b><ingrained habit></b> The RFC links below yield a plain text (nrmative) version which was copied to our site when the RFC was issued. We started this service a long time ago when the world was young, RFCs were maintained in some strange places, occasionally moved location, and performance and reliability of the repositories was very variable (being generous). None of these conditions apply today, far from it. The RFC repository is a robust, fast service. Nevertheless, we persist in our ingrained habits for no particularly good reason (old dog...new tricks..). If you want/prefer/need more choice you are advised to use one of the links identified above, if, however, you just want to read the darned RFC, feel free to click the links below.<b></ingrained habit></b></p> <table class="t-m-s"> <tr class="g-h-n"> <td class="w-80">RFC</td> <td>Description/Status</td> </tr> <tr > <td><a href="rfc1809.txt" class="t-db">RFC 1809</a></td> <td>Using the Flow Label Field in IPv6. C. Partridge. June 1995. (Format: TXT=13591 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc1881.txt" class="t-db">RFC 1881</a></td> <td>IPv6 Address Allocation Management. IAB, IESG. December 1995. (Format: TXT=3215 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc1883.txt" class="t-db">RFC 1883</a></td> <td>Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1995. (Format: TXT=82089 bytes) (Obsoleted by RFC2460) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc1885.txt" class="t-db">RFC 1885</a></td> <td>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6). A. Conta, S. Deering. December 1995. (Format: TXT=32214 bytes) (Obsoleted by RFC2463) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc1887.txt" class="t-db">RFC 1887</a></td> <td>An Architecture for IPv6 Unicast Address Allocation. Y. Rekhter, T. Li, Eds.. December 1995. (Format: TXT=66066 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc1888.txt" class="t-db">RFC 1888</a></td> <td>OSI NSAPs and IPv6. J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. August 1996. (Format: TXT=36469 bytes) (Status: EXPERIMENTAL)</td> </tr> <tr > <td><a href="rfc1924.txt" class="t-db">RFC 1924</a></td> <td>A Compact Representation of IPv6 Addresses. R. Elz. Apr-01-1996. (Format: TXT=10409 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc1932.txt" class="t-db">RFC 1932</a></td> <td>IP over ATM: A Framework Document. R. Cole, D. Shur, C. Villamizar. April 1996. (Format: TXT=68031 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc2080.txt" class="t-db">RFC 2080</a></td> <td>RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: TXT=47534 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2375.txt" class="t-db">RFC 2375</a></td> <td>IPv6 Multicast Address Assignments. R. Hinden, S. Deering. July 1998. (Format: TXT=14356 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc2428.txt" class="t-db">RFC 2428</a></td> <td>FTP Extensions for IPv6 and NATs. M. Allman, S. Ostermann, C. Metz. September 1998. (Format: TXT=16028 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2460.txt" class="t-db">RFC 2460</a></td> <td>Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1998. (Format: TXT=85490 bytes) (Obsoletes RFC1883) (Updated by RFC5095, RFC5722) (Status: DRAFT STANDARD)</td> </tr> <tr > <td><a href="rfc2461.txt" class="t-db">RFC 2461</a></td> <td>Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. December 1998. (Format: TXT=222516 bytes) (Obsoletes RFC1970) (Status: DRAFT STANDARD)</td> </tr> <tr > <td><a href="rfc2462.txt" class="t-db">RFC 2462</a></td> <td>IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998. (Format: TXT=61210 bytes) (Obsoletes RFC1971) (Status: DRAFT STANDARD)</td> </tr> <tr > <td><a href="rfc2463.txt" class="t-db">RFC 2463</a></td> <td>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering. December 1998. (Format: TXT=34190 bytes) (Obsoletes RFC1885) (Status: DRAFT STANDARD)</td> </tr> <tr > <td><a href="rfc2464.txt" class="t-db">RFC 2464</a></td> <td>Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. December 1998. (Format: TXT=12725 bytes) (Obsoletes RFC1972) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2465.txt" class="t-db">RFC 2465</a></td> <td>Management Information Base for IP Version 6: Textual Conventions and General Group. D. Haskin, S. Onishi. December 1998. (Format: TXT=77339 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2466.txt" class="t-db">RFC 2466</a></td> <td>Management Information Base for IP Version 6: ICMPv6 Group. D. Haskin, S. Onishi. December 1998. (Format: TXT=27547 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2467.txt" class="t-db">RFC 2467</a></td> <td>Transmission of IPv6 Packets over FDDI Networks. M. Crawford. December 1998. (Format: TXT=16028 bytes) (Obsoletes RFC2019) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2492.txt" class="t-db">RFC 2492</a></td> <td>IPv6 over ATM Networks. G. Armitage, P. Schulter, M. Jork. January 1999. (Format: TXT=21199 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2526.txt" class="t-db">RFC 2526</a></td> <td>Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S. Deering. March 1999. (Format: TXT=14555 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2529.txt" class="t-db">RFC 2529</a></td> <td>Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. B. Carpenter, C. Jung. March 1999. (Format: TXT=21049 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2545.txt" class="t-db">RFC 2545</a></td> <td>Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. P. Marques, F. Dupont. March 1999. (Format: TXT=10209 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2673.txt" class="t-db">RFC 2673</a></td> <td>Binary Labels in the Domain Name System. M. Crawford. August 1999. (Format: TXT=12379 bytes) (Updated by RFC3363, RFC3364) (Status: EXPERIMENTAL)</td> </tr> <tr > <td><a href="rfc2675.txt" class="t-db">RFC 2675</a></td> <td>IPv6 Jumbograms. D. Borman, S. Deering, R. Hinden. August 1999. (Format: TXT=17320 bytes) (Obsoletes RFC2147) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2710.txt" class="t-db">RFC 2710</a></td> <td>Multicast Listener Discovery (MLD) for IPv6. S. Deering, W. Fenner, B. Haberman. October 1999. (Format: TXT=46838 bytes) (Updated by RFC3590, RFC3810) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2711.txt" class="t-db">RFC 2711</a></td> <td>IPv6 Router Alert Option. C. Partridge, A. Jackson. October 1999. (Format: TXT=11973 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2732.txt" class="t-db">RFC 2732</a></td> <td>Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. December 1999. (Format: TXT=7984 bytes) (Updates RFC2396) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2740.txt" class="t-db">RFC 2740</a></td> <td>OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999. (Format: TXT=189810 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2766.txt" class="t-db">RFC 2766</a></td> <td>Network Address Translation - Protocol Translation (NAT-PT). G. Tsirtsis, P. Srisuresh. February 2000. (Format: TXT=49836 bytes) (Updated by RFC3152) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2893.txt" class="t-db">RFC 2893</a></td> <td>Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. August 2000. (Format: TXT=62731 bytes) (Obsoletes RFC1933) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2894.txt" class="t-db">RFC 2894</a></td> <td>Router Renumbering for IPv6. M. Crawford. August 2000. (Format: TXT=69135 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc2928.txt" class="t-db">RFC 2928</a></td> <td>Initial IPv6 Sub-TLA ID Assignments. R. Hinden, S. Deering, R. Fink, T. Hain. September 2000. (Format: TXT=11882 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc3041.txt" class="t-db">RFC 3041</a></td> <td>Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves. January 2001. (Format: TXT=44446 bytes) (Obsoleted by RFC4941) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc3056.txt" class="t-db">RFC 3056</a></td> <td>Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore. February 2001. (Format: TXT=54902 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3111.txt" class="t-db">RFC 3111</a></td> <td>Service Location Protocol Modifications for IPv6. E. Guttman. May 2001. (Format: TXT=25543 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3122.txt" class="t-db">RFC 3122</a></td> <td>Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. A. Conta. June 2001. (Format: TXT=40416 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3146.txt" class="t-db">RFC 3146</a></td> <td>Transmission of IPv6 Packets over IEEE 1394 Networks. K. Fujisawa, A. Onoe. October 2001. (Format: TXT=16569 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3152.txt" class="t-db">RFC 3152</a></td> <td>Delegation of IP6.ARPA. R. Bush. August 2001. (Format: TXT=5727 bytes) (Obsoleted by RFC3596) (Updates RFC2874, RFC2772, RFC2766, RFC2553, RFC1886) (Also BCP0049) (Status: BEST CURRENT PRACTICE)</td> </tr> <tr > <td><a href="rfc3162.txt" class="t-db">RFC 3162</a></td> <td>RADIUS and IPv6. B. Aboba, G. Zorn, D. Mitton. August 2001. (Format: TXT=20492 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3175.txt" class="t-db">RFC 3175</a></td> <td>Aggregation of RSVP for IPv4 and IPv6 Reservations. F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. September 2001. (Format: TXT=88681 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3177.txt" class="t-db">RFC 3177</a></td> <td>IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. (Format: TXT=23178 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc3266.txt" class="t-db">RFC 3266</a></td> <td>Support for IPv6 in Session Description Protocol (SDP). S. Olson, G. Camarillo, A. B. Roach. June 2002. (Format: TXT=8693 bytes) (Updates RFC2327) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3306.txt" class="t-db">RFC 3306</a></td> <td>Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D. Thaler. August 2002. (Format: TXT=12713 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3307.txt" class="t-db">RFC 3307</a></td> <td>Allocation Guidelines for IPv6 Multicast Addresses. B. Haberman. August 2002. (Format: TXT=15742 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3314.txt" class="t-db">RFC 3314</a></td> <td>Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards. M. Wasserman, Ed.. September 2002. (Format: TXT=48168 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc3315.txt" class="t-db">RFC 3315</a></td> <td>Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003. (Format: TXT=231402 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3363.txt" class="t-db">RFC 3363</a></td> <td>Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain. August 2002. (Format: TXT=11055 bytes) (Updates RFC2673, RFC2874) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc3364.txt" class="t-db">RFC 3364</a></td> <td>Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6). R. Austein. August 2002. (Format: TXT=26544 bytes) (Updates RFC2673, RFC2874) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc3484.txt" class="t-db">RFC 3484</a></td> <td>Default Address Selection for Internet Protocol version 6 (IPv6). R. Draves. February 2003. (Format: TXT=55076 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3513.txt" class="t-db">RFC 3513</a></td> <td>Internet Protocol Version 6 (IPv6) Addressing Architecture. R. Hinden, S. Deering. April 2003. (Format: TXT=53920 bytes) (Obsoletes RFC2373) (Status: obsoleted by RFC4291)</td> </tr> <tr > <td><a href="rfc3587.txt" class="t-db">RFC 3587</a></td> <td>IPv6 Global Unicast Address Format. R. Hinden, S. Deering, E. Nordmark. August 2003. (Format: TXT=8783 bytes) (Obsoletes RFC2374) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc3596.txt" class="t-db">RFC 3596</a></td> <td>DNS Extensions to Support IP Version 6. S. Thomson, C. Huitema, V. Ksinant, M. Souissi. October 2003. (Format: TXT=14093 bytes) (Obsoletes RFC3152, RFC1886) (Status: DRAFT STANDARD)</td> </tr> <tr > <td><a href="rfc3633.txt" class="t-db">RFC 3633</a></td> <td>IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6. O. Troan, R. Droms. December 2003. (Format: TXT=45308 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3646.txt" class="t-db">RFC 3646</a></td> <td>DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed.. December 2003. (Format: TXT=13312 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3697.txt" class="t-db">RFC 3697</a></td> <td>IPv6 Flow Label Specification. J. Rajahalme, A. Conta, B. Carpenter, S. Deering. March 2004. (Format: TXT=21296 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3736.txt" class="t-db">RFC 3736</a></td> <td>Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. R. Droms. April 2004. (Format: TXT=18510 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3775.txt" class="t-db">RFC 3775</a></td> <td>Mobility Support in IPv6. D. Johnson, C. Perkins, J. Arkko. June 2004. (Format: TXT=393514 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3776.txt" class="t-db">RFC 3776</a></td> <td>Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. J. Arkko, V. Devarapalli, F. Dupont. June 2004. (Format: TXT=87076 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3810.txt" class="t-db">RFC 3810</a></td> <td>Multicast Listener Discovery Version 2 (MLDv2) for IPv6. R. Vida, Ed., L. Costa, Ed.. June 2004. (Format: TXT=153579 bytes) (Updates RFC2710) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3831.txt" class="t-db">RFC 3831</a></td> <td>Transmission of IPv6 Packets over Fibre Channel. C. DeSanti. July 2004. (Format: TXT=53328 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc3849.txt" class="t-db">RFC 3849</a></td> <td>IPv6 Address Prefix Reserved for Documentation. G. Huston, A. Lord, P. Smith. July 2004. (Format: TXT=7872 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc3901.txt" class="t-db">RFC 3901</a></td> <td>DNS IPv6 Transport Operational Guidelines. A. Durand, J. Ihren. September 2004. (Format: TXT=10025 bytes) (Also BCP0091) (Status: BEST CURRENT PRACTICE)</td> </tr> <tr > <td><a href="rfc3956.txt" class="t-db">RFC 3956</a></td> <td>Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. P. Savola, B. Haberman. November 2004. (Format: TXT=40136 bytes) (Updates RFC3306) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4007.txt" class="t-db">RFC 4007</a></td> <td>IPv6 Scoped Address Architecture. S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill. March 2005. (Format: TXT=53555 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4038.txt" class="t-db">RFC 4038</a></td> <td>Application Aspects of IPv6 Transition. M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro. March 2005. (Format: TXT=69727 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc4074.txt" class="t-db">RFC 4074</a></td> <td>Common Misbehavior Against DNS Queries for IPv6 Addresses. Y. Morishita, T. Jinmei. May 2005. (Format: TXT=13073 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc4147.txt" class="t-db">RFC 4147</a></td> <td>Proposed Changes to the Format of the IANA IPv6 Registry. G. Huston. August 2005. (Format: TXT=21196 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc4193.txt" class="t-db">RFC 4193</a></td> <td>Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman. October 2005. (Format: TXT=35908 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4213.txt" class="t-db">RFC 4213</a></td> <td>Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark, R. Gilligan. October 2005. (Format: TXT=58575 bytes) (Obsoletes RFC2893) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4215.txt" class="t-db">RFC 4215</a></td> <td>Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks. J. Wiljakka, Ed.. October 2005. (Format: TXT=52903 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc4242.txt" class="t-db">RFC 4242</a></td> <td>Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). S. Venaas, T. Chown, B. Volz. November 2005. (Format: TXT=14759 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4260.txt" class="t-db">RFC 4260</a></td> <td>Mobile IPv6 Fast Handovers for 802.11 Networks. P. McCann. November 2005. (Format: TXT=35276 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc4283.txt" class="t-db">RFC 4283</a></td> <td>Mobile Node Identifier Option for Mobile IPv6 (MIPv6). A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. November 2005. (Format: TXT=14653 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4283.txt" class="t-db">RFC 4283</a></td> <td>Mobile Node Identifier Option for Mobile IPv6 (MIPv6). A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. November 2005. (Format: TXT=14653 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4291.txt" class="t-db">RFC 4291</a></td> <td>IP Version 6 Addressing Architecture. R. Hinden, S. Deering. February 2006. (Format: TXT=52897 bytes) (Obsoletes RFC3513) (Status: DRAFT STANDARD)</td> </tr> <tr > <td><a href="rfc4295.txt" class="t-db">RFC 4295</a></td> <td>Mobile IPv6 Management Information Base. G. Keeni, K. Koide, K. Nagami, S. Gundavelli. April 2006. (Format: TXT=209038 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4311.txt" class="t-db">RFC 4311</a></td> <td>IPv6 Host-to-Router Load Sharing. R. Hinden, D. Thaler. November 2005. (Format: TXT=10156 bytes) (Updates RFC2461) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4339.txt" class="t-db">RFC 4339</a></td> <td>IPv6 Host Configuration of DNS Server Information Approaches. J. Jeong, Ed.. February 2006. (Format: TXT=60803 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc4380.txt" class="t-db">RFC 4380</a></td> <td>Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). C. Huitema. February 2006. (Format: TXT=132607 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4429.txt" class="t-db">RFC 4429</a></td> <td>Optimistic Duplicate Address Detection (DAD) for IPv6. N. Moore. April 2006. (Format: TXT=33123 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4443.txt" class="t-db">RFC 4443</a></td> <td>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M. Gupta, Ed.. March 2006. (Format: TXT=48969 bytes) (Obsoletes RFC2463) (Updates RFC2780) (Status: INTERNET STANDARD)</td> </tr> <tr > <td><a href="rfc4449.txt" class="t-db">RFC 4449</a></td> <td>Securing Mobile IPv6 Route Optimization Using a Static Shared Key. C. Perkins. June 2006. (Format: TXT=15080 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4489.txt" class="t-db">RFC 4489</a></td> <td>A Method for Generating Link-Scoped IPv6 Multicast Addresses. J-S. Park, M-K. Shin, H-J. Kim. April 2006. (Format: TXT=12224 bytes) (Updates RFC3306) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4649.txt" class="t-db">RFC 4649</a></td> <td>Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option. B. Volz. August 2006. (Format: TXT=10940 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4704.txt" class="t-db">RFC 4704</a></td> <td>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option. B. Volz. October 2006. (Format: TXT=32359 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4727.txt" class="t-db">RFC 4727</a></td> <td>Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. B. Fenner. November 2006. (Format: TXT=19745 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc4773.txt" class="t-db">RFC 4773</a></td> <td>Administration of the IANA Special Purpose IPv6 Address Block. G. Huston. December 2006. (Format: TXT=10580 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc4776.txt" class="t-db">RFC 4776</a></td> <td>Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. H. Schulzrinne. November 2006. (Format: TXT=45495 bytes) (Obsoletes RFC4676) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc4779.txt" class="t-db">RFC 4779</a></td> <td>ISP IPv6 Deployment Scenarios in Broadband Access Networks. S. Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet. January 2007. (Format: TXT=188511 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc4798.txt" class="t-db">RFC 4798</a></td> <td>Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE). J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur. February 2007. (Format: TXT=31381 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc4818.txt" class="t-db">RFC 4818</a></td> <td>RADIUS Delegated-IPv6-Prefix Attribute. J. Salowey, R. Droms. April 2007. (Format: TXT=12993 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc4843.txt" class="t-db">RFC 4843</a></td> <td>An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID). P. Nikander, J. Laganier, F. Dupont. April 2007. (Format: TXT=32483 bytes) (Status: EXPERIMENTAL) </td> </tr> <tr > <td><a href="rfc4852.txt" class="t-db">RFC 4852</a></td> <td>IPv6 Enterprise Network Analysis - IP Layer 3 Focus. J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green. April 2007. (Format: TXT=76199 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc4861.txt" class="t-db">RFC 4861</a></td> <td>Neighbor Discovery for IP version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson, H. Soliman. September 2007. (Format: TXT=235106 bytes) (Obsoletes RFC2461) (Status: DRAFT STANDARD) </td> </tr> <tr > <td><a href="rfc4862.txt" class="t-db">RFC 4862</a></td> <td>IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten, T. Jinmei. September 2007. (Format: TXT=72482 bytes) (Obsoletes RFC2462) (Status: DRAFT STANDARD) </td> </tr> <tr > <td><a href="rfc4864.txt" class="t-db">RFC 4864</a></td> <td>Local Network Protection for IPv6. G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein. May 2007. (Format: TXT=95448 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc4866.txt" class="t-db">RFC 4866</a></td> <td>Enhanced Route Optimization for Mobile IPv6. J. Arkko, C. Vogt, W. Haddad. May 2007. (Format: TXT=145757 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc4877.txt" class="t-db">RFC 4877</a></td> <td>Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture. V. Devarapalli, F. Dupont. April 2007. (Format: TXT=57941 bytes) (Updates RFC3776) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc4882.txt" class="t-db">RFC 4882</a></td> <td>IP Address Location Privacy and Mobile IPv6: Problem Statement. R. Koodli. May 2007. (Format: TXT=24987 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc4890.txt" class="t-db">RFC 4890</a></td> <td>Recommendations for Filtering ICMPv6 Messages in Firewalls. E. Davies, J. Mohacsi. May 2007. (Format: TXT=83479 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc4891.txt" class="t-db">RFC 4891</a></td> <td>Using IPsec to Secure IPv6-in-IPv4 Tunnels. R. Graveman, M. Parthasarathy, P. Savola, H. Tschofenig. May 2007. (Format: TXT=46635 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc4919.txt" class="t-db">RFC 4919</a></td> <td>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. N. Kushalnagar, G. Montenegro, C. Schumacher. August 2007. (Format: TXT=27650 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc4941.txt" class="t-db">RFC 4941</a></td> <td>Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format: TXT=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD) </td> </tr> <tr > <td><a href="rfc4942.txt" class="t-db">RFC 4942</a></td> <td>IPv6 Transition/Co-existence Security Considerations. E. Davies, S. Krishnan, P. Savola. September 2007. (Format: TXT=102878 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc4943.txt" class="t-db">RFC 4943</a></td> <td>IPv6 Neighbor Discovery On-Link Assumption Considered Harmful. S. Roy, A. Durand, J. Paugh. September 2007. (Format: TXT=16719 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc4944.txt" class="t-db">RFC 4944</a></td> <td>Transmission of IPv6 Packets over IEEE 802.15.4 Networks. G. Montenegro, N. Kushalnagar, J. Hui, D. Culler. September 2007. (Format: TXT=67232 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc4968.txt" class="t-db">RFC 4968</a></td> <td>Analysis of IPv6 Link Models for 802.16 Based Networks. S. Madanapalli, Ed.. August 2007. (Format: TXT=34536 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc5006.txt" class="t-db">RFC 5006</a></td> <td>IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: TXT=26136 bytes) (Status: EXPERIMENTAL) </td> </tr> <tr > <td><a href="rfc5007.txt" class="t-db">RFC 5007</a></td> <td>DHCPv6 Leasequery. J. Brzozowski, K. Kinnear, B. Volz, S. Zeng. September 2007. (Format: TXT=47186 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc5014.txt" class="t-db">RFC 5014</a></td> <td>IPv6 Socket API for Source Address Selection. E. Nordmark, S. Chakrabarti, J. Laganier. September 2007. (Format: TXT=53601 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc5026.txt" class="t-db">RFC 5026</a></td> <td>Mobile IPv6 Bootstrapping in Split Scenario. G. Giaretta, Ed., J. Kempf, V. Devarapalli, Ed.. October 2007. (Format: TXT=63138 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc5072.txt" class="t-db">RFC 5072</a></td> <td>IP Version 6 over PPP. S.Varada, Ed., D. Haskins, E. Allen. September 2007. (Format: TXT=33910 bytes) (Obsoletes RFC2472) (Status: DRAFT STANDARD) </td> </tr> <tr > <td><a href="rfc5094.txt" class="t-db">RFC 5094</a></td> <td>Mobile IPv6 Vendor Specific Option. V. Devarapalli, A. Patel, K. Leung. December 2007. (Format: TXT=11430 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc5095.txt" class="t-db">RFC 5095</a></td> <td>Deprecation of Type 0 Routing Headers in IPv6. J. Abley, P. Savola, G. Neville-Neil. December 2007. (Format: TXT=13423 bytes) (Updates RFC2460, RFC4294) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc5096.txt" class="t-db">RFC 5096</a></td> <td>Mobile IPv6 Experimental Messages. V. Devarapalli. December 2007. (Format: TXT=13669 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc5121.txt" class="t-db">RFC 5121</a></td> <td>Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks. B. Patil, F. Xia, B. Sarikaya, JH. Choi, S. Madanapalli. February 2008. (Format: TXT=50092 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc5149.txt" class="t-db">RFC 5149</a></td> <td>Service Selection for Mobile IPv6. J. Korhonen, U. Nilsson, V. Devarapalli. February 2008. (Format: TXT=18746 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc5156.txt" class="t-db">RFC 5156</a></td> <td>Special-Use IPv6 Addresses. M. Blanchet. April 2008. (Format: TXT=11931 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc5157.txt" class="t-db">RFC 5157</a></td> <td>IPv6 Implications for Network Scanning. T. Chown. March 2008. (Format: TXT=29054 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc5158.txt" class="t-db">RFC 5158</a></td> <td>6to4 Reverse DNS Delegation Specification. G. Huston. March 2008. (Format: TXT=25536 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc5175.txt" class="t-db">RFC 5175</a></td> <td>IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. March 2008. (Format: TXT=12463 bytes) (Obsoletes RFC5075) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc5180.txt" class="t-db">RFC 5180</a></td> <td>IPv6 Benchmarking Methodology for Network Interconnect Devices. C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin. May 2008. (Format: TXT=41712 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc5181.txt" class="t-db">RFC 5181</a></td> <td>IPv6 Deployment Scenarios in 802.16 Networks. M-K. Shin, Ed., Y-H. Han, S-E. Kim, D. Premec. May 2008. (Format: TXT=36671 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc5213.txt" class="t-db">RFC 5213</a></td> <td>Proxy Mobile IPv6. S. Gundavelli, Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil. August 2008. (Format: TXT=226902 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc5269.txt" class="t-db">RFC 5269</a></td> <td>Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND). J. Kempf, R. Koodli. June 2008. (Format: TXT=32742 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc5270.txt" class="t-db">RFC 5270</a></td> <td>Mobile IPv6 Fast Handovers over IEEE 802.16e Networks. H. Jang, J. Jee, Y. Han, S. Park, J. Cha. June 2008. (Format: TXT=42358 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc5271.txt" class="t-db">RFC 5271</a></td> <td>Mobile IPv6 Fast Handovers for 3G CDMA Networks. H. Yokota, G. Dommety. June 2008. (Format: TXT=49316 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc5375.txt" class="t-db">RFC 5375</a></td> <td>IPv6 Unicast Address Assignment Considerations. G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn. December 2008. (Format: TXT=83809 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc5380.txt" class="t-db">RFC 5380</a></td> <td>Hierarchical Mobile IPv6 (HMIPv6) Mobility Management. H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier. October 2008. (Format: TXT=58330 bytes) (Obsoletes RFC4140) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc5419.txt" class="t-db">RFC 5419</a></td> <td>Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6). B. Patil, G. Dommety. January 2009. (Format: TXT=45178 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc5447.txt" class="t-db">RFC 5447</a></td> <td>Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction. J. Korhonen, Ed., J. Bournelle, H. Tschofenig, C. Perkins, K. Chowdhury. February 2009. (Format: TXT=38656 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc5453.txt" class="t-db">RFC 5453</a></td> <td>Reserved IPv6 Interface Identifiers. S. Krishnan. February 2009. (Format: TXT=11754 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc5534.txt" class="t-db">RFC 5534</a></td> <td>Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming. J. Arkko, I. van Beijnum. June 2009. (Format: TXT=88152 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc5555.txt" class="t-db">RFC 5555</a></td> <td>Mobile IPv6 Support for Dual Stack Hosts and Routers. H. Soliman, Ed.. June 2009. (Format: TXT=92387 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc5568.txt" class="t-db">RFC 5568</a></td> <td>Mobile IPv6 Fast Handovers. R. Koodli, Ed.. July 2009. (Format: TXT=121373 bytes) (Obsoletes RFC5268) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc5569.txt" class="t-db">RFC 5569</a></td> <td>IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). R. Despres. January 2010. (Format: TXT=21159 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc5570.txt" class="t-db">RFC 5570</a></td> <td>Common Architecture Label IPv6 Security Option (CALIPSO). M. StJohns, R. Atkinson, G. Thomas. July 2009. (Format: TXT=128032 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc5637.txt" class="t-db">RFC 5637</a></td> <td>Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6. G. Giaretta, I. Guardini, E. Demaria, J. Bournelle, R. Lopez. September 2009. (Format: TXT=23409 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc5722.txt" class="t-db">RFC 5722</a></td> <td>Handling of Overlapping IPv6 Fragments. S. Krishnan. December 2009. (Format: TXT=11838 bytes) (Updates RFC2460) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc5844.txt" class="t-db">RFC 5844</a></td> <td>IPv4 Support for Proxy Mobile IPv6. R. Wakikawa, S. Gundavelli. May 2010. (Format: TXT=116102 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc5952.txt" class="t-db">RFC 5952</a></td> <td>A Recommendation for IPv6 Address Text Representation. S. Kawamura, M. Kawashima. August 2010. (Format: TXT=26570 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc5969.txt" class="t-db">RFC 5969</a></td> <td>IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification. W. Townsley, O. Troan. August 2010. (Format: TXT=45278 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc6052.txt" class="t-db">RFC 6052</a></td> <td>IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=41849 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc6058.txt" class="t-db">RFC 6058</a></td> <td>Transient Binding for Proxy Mobile IPv6. M. Liebsch, A. Muhanna, O. Blume. March 2011. (Obsoletes RFC3177) (Status: EXPERIMENTAL)</td> </tr> <tr > <td><a href="rfc6106.txt" class="t-db">RFC 6106</a></td> <td>IPv6 Router Advertisement Options for DNS Configuration. J. Jeong, S. Park, L. Beloeil, S. Madanapalli. November 2010. (Format: TXT=45181 bytes) (Obsoletes RFC5006) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc6144.txt" class="t-db">RFC 6144</a></td> <td>Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. Yin. April 2011. (Format: TXT=67181 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6146.txt" class="t-db">RFC 6146</a></td> <td>Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=107954 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6156.txt" class="t-db">RFC 6156</a></td> <td>Traversal Using Relays around NAT (TURN) Extension for IPv6. G. Camarillo, O. Novo, S. Perreault, Ed.. April 2011. (Format: TXT=27758 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6177.txt" class="t-db">RFC 6177</a></td> <td>IPv6 Address Assignment to End Sites. T. Narten, G. Huston, L. Roberts. March 2011. (Obsoletes RFC3177) (Status: BEST CURRENT PRACTICE)</td> </tr> <tr > <td><a href="rfc6180.txt" class="t-db">RFC 6180</a></td> <td>Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=49679 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6264.txt" class="t-db">RFC 6264</a></td> <td>An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition. S. Jiang, D. Guo, B. Carpenter. June 2011. (Format: TXT=31881 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6275.txt" class="t-db">RFC 6275</a></td> <td>Mobility Support in IPv6. C. Perkins, Ed., D. Johnson, J. Arkko. July 2011. (Format: TXT=405488 bytes) (Obsoletes RFC3775) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6282.txt" class="t-db">RFC 6282</a></td> <td>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks. J. Hui, Ed., P. Thubert. September 2011. (Format: TXT=52588 bytes) (Updates RFC4944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6282)</td> </tr> <tr > <td><a href="rfc6296.txt" class="t-db">RFC 6296</a></td> <td>IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL)</td> </tr> <tr > <td><a href="rfc6333.txt" class="t-db">RFC 6333</a></td> <td>Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion. A. Durand, R. Droms, J. Woodyatt, Y. Lee. August 2011. (Format: TXT=65622 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6334.txt" class="t-db">RFC 6334</a></td> <td>Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite. D. Hankins, T. Mrugalski. August 2011. (Format: TXT=14362 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6342.txt" class="t-db">RFC 6342</a></td> <td>Mobile Networks Considerations for IPv6 Deployment. R. Koodli. August 2011. (Format: TXT=46288 bytes) (Obsoletes RFC6312) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6343.txt" class="t-db">RFC 6343</a></td> <td>Advisory Guidelines for 6to4 Deployment. B. Carpenter. August 2011. (Format: TXT=51496 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6434.txt" class="t-db">RFC 6434</a></td> <td>IPv6 Node Requirements. E. Jankiewicz, J. Loughney, T. Narten. December 2011. (Format: TXT=64407 bytes) (Obsoletes RFC4294) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc6459.txt" class="t-db">RFC 6459</a></td> <td>IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS). J. Korhonen, Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila. January 2012. (Format: TXT=84769 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc6535.txt" class="t-db">RFC 6535</a></td> <td>Dual-Stack Hosts Using "Bump-in-the-Host" (BIH). B. Huang, H. Deng, T. Savolainen. February 2012. (Format: TXT=54452 bytes) (Obsoletes RFC2767, RFC3338) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc6540.txt" class="t-db">RFC 6540</a></td> <td>IPv6 Support Required for All IP-Capable Nodes. W. George, C. Donley, C. Liljenstolpe, L. Howard. April 2012. (Format: TXT=12883 bytes) (Also BCP0177) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc6543.txt" class="t-db">RFC 6543</a></td> <td>Reserved IPv6 Interface Identifier for Proxy Mobile IPv6. S. Gundavelli. May 2012. (Format: TXT=10565 bytes) (Updates RFC5213) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6547.txt" class="t-db">RFC 6547</a></td> <td>RFC 3627 to Historic Status. W. George. February 2012. (Format: TXT=4917 bytes) (Obsoletes RFC3627) (Updates RFC6164) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc6602.txt" class="t-db">RFC 6602</a></td> <td>Bulk Binding Update Support for Proxy Mobile IPv6. F. Abinader, Ed., S. Gundavelli, Ed., K. Leung, S. Krishnan, D. Premec. May 2012. (Format: TXT=56348 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6606.txt" class="t-db">RFC 6606</a></td> <td>Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing. E. Kim, D. Kaspar, C. Gomez, C. Bormann. May 2012. (Format: TXT=75436 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6610.txt" class="t-db">RFC 6610</a></td> <td>DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6). H. Jang, A. Yegin, K. Chowdhury, J. Choi, T. Lemon. May 2012. (Format: TXT=36878 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6611.txt" class="t-db">RFC 6611</a></td> <td>Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario. K. Chowdhury, Ed., A. Yegin. May 2012. (Format: TXT=27152 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6612.txt" class="t-db">RFC 6612</a></td> <td>Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues. G. Giaretta, Ed.. May 2012. (Format: TXT=40116 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6618.txt" class="t-db">RFC 6618</a></td> <td>Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent. J. Korhonen, Ed., B. Patil, H. Tschofenig, D. Kroeselberg. May 2012. (Format: TXT=87475 bytes) (Status: EXPERIMENTAL)</td> </tr> <tr > <td><a href="rfc6654.txt" class="t-db">RFC 6654</a></td> <td>Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd). T. Tsou, C. Zhou, T. Taylor, Q. Chen. July 2012. (Format: TXT=16949 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6705.txt" class="t-db">RFC 6705</a></td> <td>Localized Routing for Proxy Mobile IPv6. S. Krishnan, R. Koodli, P. Loureiro, Q. Wu, A. Dutta. September 2012. (Format: TXT=43309 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc6724.txt" class="t-db">RFC 6724</a></td> <td>Default Address Selection for Internet Protocol Version 6 (IPv6). D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown. September 2012. (Format: TXT=74407 bytes) (Obsoletes RFC3484) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc6732.txt" class="t-db">RFC 6732</a></td> <td>6to4 Provider Managed Tunnels. V. Kuarsingh, Ed., Y. Lee, O. Vautrin. September 2012. (Format: TXT=28156 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6743.txt" class="t-db">RFC 6743</a></td> <td>ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=24972 bytes) (Status: EXPERIMENTAL) </td> </tr> <tr > <td><a href="rfc6744.txt" class="t-db">RFC 6744</a></td> <td>IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=33737 bytes) (Status: EXPERIMENTAL) </td> </tr> <tr > <td><a href="rfc6751.txt" class="t-db">RFC 6751</a></td> <td>Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44). R. Despres, Ed., B. Carpenter, D. Wing, S. Jiang. October 2012. (Format: TXT=73468 bytes) (Status: EXPERIMENTAL) </td> </tr> <tr > <td><a href="rfc6757.txt" class="t-db">RFC 6757</a></td> <td>Access Network Identifier (ANI) Option for Proxy Mobile IPv6. S. Gundavelli, Ed., J. Korhonen, Ed., M. Grayson, K. Leung, R. Pazhyannur. October 2012. (Format: TXT=43863 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6775.txt" class="t-db">RFC 6775</a></td> <td>Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). Z. Shelby, Ed., S. Chakrabarti, E. Nordmark, C. Bormann. November 2012. (Format: TXT=130616 bytes) (Updates RFC4944) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6782.txt" class="t-db">RFC 6782</a></td> <td>Wireline Incremental IPv6. V. Kuarsingh, Ed., L. Howard. November 2012. (Format: TXT=71197 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6784.txt" class="t-db">RFC 6784</a></td> <td>Kerberos Options for DHCPv6. S. Sakane, M. Ishiyama. November 2012. (Format: TXT=24110 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6791.txt" class="t-db">RFC 6791</a></td> <td>Stateless Source Address Mapping for ICMPv6 Packets. X. Li, C. Bao, D. Wing, R. Vaithianathan, G. Huston. November 2012. (Format: TXT=11793 bytes) (Updates RFC6145) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6866.txt" class="t-db">RFC 6866</a></td> <td>Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks. B. Carpenter, S. Jiang. February 2013. (Format: TXT=26524 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6874.txt" class="t-db">RFC 6874</a></td> <td>Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. B. Carpenter, S. Cheshire, R. Hinden. February 2013. (Format: TXT=19361 bytes) (Updates RFC3986) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6879.txt" class="t-db">RFC 6879</a></td> <td>IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods. S. Jiang, B. Liu, B. Carpenter. February 2013. (Format: TXT=38833 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6883.txt" class="t-db">RFC 6883</a></td> <td>IPv6 Guidance for Internet Content Providers and Application Service Providers. B. Carpenter, S. Jiang. March 2013. (Format: TXT=60430 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6946.txt" class="t-db">RFC 6946</a></td> <td>Processing of IPv6 "Atomic" Fragments. F. Gont. May 2013. (Format: TXT=18843 bytes) (Updates RFC2460, RFC5722) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6957.txt" class="t-db">RFC 6957</a></td> <td>Duplicate Address Detection Proxy. F. Costa, J-M. Combes, Ed., X. Pougnard, H. Li. June 2013. (Format: TXT=32537 bytes) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc6964.txt" class="t-db">RFC 6964</a></td> <td>Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin. May 2013. (Format: TXT=49568 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc6980.txt" class="t-db">RFC 6980</a></td> <td>Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery. F. Gont. August 2013. (Format: TXT=20850 bytes) (Updates RFC3971, RFC4861) (Status: PROPOSED STANDARD)</td> </tr> <tr > <td><a href="rfc7021.txt" class="t-db">RFC 7021</a></td> <td>Assessing the Impact of Carrier-Grade NAT on Network Applications. C. Donley, Ed., L. Howard, V. Kuarsingh, J. Berg, J. Doshi. September 2013. (Format: TXT=66150 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc7028.txt" class="t-db">RFC 7028</a></td> <td>Multicast Mobility Routing Optimizations for Proxy Mobile IPv6. JC. Zuniga, LM. Contreras, CJ. Bernardos, S. Jeon, Y. Kim. September 2013. (Format: TXT=63110 bytes) (Status: EXPERIMENTAL)</td> </tr> <tr > <td><a href="rfc7031.txt" class="t-db">RFC 7031</a></td> <td>DHCPv6 Failover Requirements. T. Mrugalski, K. Kinnear. September 2013. (Format: TXT=39321 bytes) (Status: INFORMATIONAL)</td> </tr> <tr > <td><a href="rfc7040.txt" class="t-db">RFC 7040</a></td> <td>Public IPv4-over-IPv6 Access Network. Y. Cui, J. Wu, P. Wu, O. Vautrin, Y. Lee. November 2013. (Format: TXT=27273 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc7045.txt" class="t-db">RFC 7045</a></td> <td>Transmission and Processing of IPv6 Extension Headers. B. Carpenter, S. Jiang. December 2013. (Format: TXT=21852 bytes) (Updates RFC2460, RFC2780) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc7050.txt" class="t-db">RFC 7050</a></td> <td>Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis. T. Savolainen, J. Korhonen, D. Wing. November 2013. (Format: TXT=50097 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr > <td><a href="rfc7051.txt" class="t-db">RFC 7051</a></td> <td>Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix. J. Korhonen, Ed., T. Savolainen, Ed.. November 2013. (Format: TXT=55248 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc7059.txt" class="t-db">RFC 7059</a></td> <td>A Comparison of IPv6-over-IPv4 Tunnel Mechanisms. S. Steffann, I. van Beijnum, R. van Rein. November 2013. (Format: TXT=98886 bytes) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc7066.txt" class="t-db">RFC 7066</a></td> <td>IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts. J. Korhonen, Ed., J. Arkko, Ed., T. Savolainen, S. Krishnan. November 2013. (Format: TXT=44253 bytes) (Obsoletes RFC3316) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc7084.txt" class="t-db">RFC 7084</a></td> <td>Basic Requirements for IPv6 Customer Edge Routers. H. Singh, W. Beebee, C. Donley, B. Stark. November 2013. (Format: TXT=46569 bytes) (Obsoletes RFC6204) (Status: INFORMATIONAL) </td> </tr> <tr > <td><a href="rfc7098.txt" class="t-db">RFC 7098</a></td> <td>Using the IPv6 Flow Label for Load Balancing in Server Farms. B. Carpenter, S. Jiang, W. Tarreau. January 2014. (Format: TXT=30884 bytes) (Status: INFORMATIONAL) </td> </tr> <tr> <td><a href="rfc7109.txt" class="t-db">RFC 7109</a></td> <td>Flow Bindings Initiated by Home Agents for Mobile IPv6. H. Yokota, D. Kim, B. Sarikaya, F. Xia. February 2014. (Format: TXT=40637 bytes) (Status: EXPERIMENTAL) </td> </tr> <tr> <td><a href="rfc7112.txt" class="t-db">RFC 7112</a></td> <td>Implications of Oversized IPv6 Header Chains. F. Gont, V. Manral, R. Bonica. January 2014. (Format: TXT=15897 bytes) (Updates RFC2460) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7125.txt" class="t-db">RFC 7125</a></td> <td>Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element. B. Trammell, P. Aitken. February 2014. (Format: TXT=11679 bytes) (Status: INFORMATIONAL) </td> </tr> <tr> <td><a href="rfc7156.txt" class="t-db">RFC 7156</a></td> <td>Diameter Support for Proxy Mobile IPv6 Localized Routing. G. Zorn, Q. Wu, J. Korhonen. April 2014. (Format: TXT=25657 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7157.txt" class="t-db">RFC 7157</a></td> <td>IPv6 Multihoming without Network Address Translation. O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing. March 2014. (Format: TXT=49038 bytes) (Status: INFORMATIONAL) </td> </tr> <tr> <td><a href="rfc7161.txt" class="t-db">RFC 7161</a></td> <td>Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL). LM. Contreras, CJ. Bernardos, I. Soto. March 2014. (Format: TXT=85916 bytes) (Status: EXPERIMENTAL) </td> </tr> <tr> <td><a href="rfc7217.txt" class="t-db">RFC 7217</a></td> <td>A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). F. Gont. April 2014. (Format: TXT=48497 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7222.txt" class="t-db">RFC 7222</a></td> <td>Quality-of-Service Option for Proxy Mobile IPv6. M. Liebsch, P. Seite, H. Yokota, J. Korhonen, S. Gundavelli. May 2014. (Format: TXT=139026 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7225.txt" class="t-db">RFC 7225</a></td> <td>Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP). M. Boucadair. May 2014. (Format: TXT=40239 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7269.txt" class="t-db">RFC 7269</a></td> <td>NAT64 Deployment Options and Experience. G. Chen, Z. Cao, C. Xie, D. Binet. June 2014. (Format: TXT=56043 bytes) (Status: INFORMATIONAL) </td> </tr> <tr> <td><a href="rfc7278.txt" class="t-db">RFC 7278</a></td> <td>Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link. C. Byrne, D. Drown, A. Vizdal. June 2014. (Format: TXT=19965 bytes) (Status: INFORMATIONAL) </td> </tr> <tr> <td><a href="rfc7343.txt" class="t-db">RFC 7343</a></td> <td>An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2). J. Laganier, F. Dupont. September 2014. (Format: TXT=28699 bytes) (Obsoletes RFC4843) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7346.txt" class="t-db">RFC 7346</a></td> <td>IPv6 Multicast Address Scopes. R. Droms. August 2014. (Format: TXT=10831 bytes) (Updates RFC4007, RFC4291) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7368.txt" class="t-db">RFC 7368</a></td> <td>IPv6 Home Networking Architecture Principles. T. Chown, Ed., J. Arkko, A. Brandt, O. Troan, J. Weil. October 2014. (Format: TXT=125402 bytes) (Status: INFORMATIONAL) </td> </tr> <tr> <td><a href="rfc7371.txt" class="t-db">RFC 7371</a></td> <td>Updates to the IPv6 Multicast Addressing Architecture. M. Boucadair, S. Venaas. September 2014. (Format: TXT=18327 bytes) (Updates RFC3306, RFC3956, RFC4291) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7381.txt" class="t-db">RFC 7381</a></td> <td>Enterprise IPv6 Deployment Guidelines. K. Chittimaneni, T. Chown, L. Howard, V. Kuarsingh, Y. Pouffary, E. Vyncke. October 2014. (Format: TXT=90299 bytes) (Status: INFORMATIONAL) </td> </tr> <tr> <td><a href="rfc7388.txt" class="t-db">RFC 7388</a></td> <td>Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). J. Schoenwaelder, A. Sehgal, T. Tsou, C. Zhou. October 2014. (Format: TXT=53451 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7389.txt" class="t-db">RFC 7389</a></td> <td>Separation of Control and User Plane for Proxy Mobile IPv6. R. Wakikawa, R. Pazhyannur, S. Gundavelli, C. Perkins. October 2014. (Format: TXT=26217 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7400.txt" class="t-db">RFC 7400</a></td> <td>6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). C. Bormann. November 2014. (Format: TXT=47533 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7400) </td> </tr> <tr> <td><a href="rfc7404.txt" class="t-db">RFC 7404</a></td> <td>Using Only Link-Local Addressing inside an IPv6 Network. M. Behringer, E. Vyncke. November 2014. (Format: TXT=24444 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7404) </td> </tr> <tr> <td><a href="rfc7411.txt" class="t-db">RFC 7411</a></td> <td>Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers. T. Schmidt, Ed., M. Waehlisch, R. Koodli, G. Fairhurst, D. Liu. November 2014. (Format: TXT=72298 bytes) (Updates RFC5568) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7411) </td> </tr> <tr> <td><a href="rfc7421.txt" class="t-db">RFC 7421</a></td> <td>Analysis of the 64-bit Boundary in IPv6 Addressing. B. Carpenter, Ed., T. Chown, F. Gont, S. Jiang, A. Petrescu, A. Yourtchenko. January 2015. (Format: TXT=60469 bytes) (Status: INFORMATIONAL) </td> </tr> <tr> <td><a href="rfc7428.txt" class="t-db">RFC 7428</a></td> <td>Transmission of IPv6 Packets over ITU-T G.9959 Networks. A. Brandt, J. Buron. February 2015. (Format: TXT=42657 bytes) (Status: PROPOSED STANDARD) </td> </tr> <tr> <td><a href="rfc7439.txt" class="t-db">RFC 7439</a></td> <td>Gap Analysis for Operating IPv6-Only MPLS Networks. W. George, Ed., C. Pignataro, Ed.. January 2015. (Format: TXT=64087 bytes) (Status: INFORMATIONAL) </td> </tr> <tr> <td><a href="rfc7526.txt" class="t-db">RFC 7526</a></td> <td>Deprecating the Anycast Prefix for 6to4 Relay Routers. O. Troan, B. Carpenter, Ed.. May 2015. (Format: TXT=20894 bytes) (Obsoletes RFC3068, RFC6732) (Also BCP0196) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7526) </td> </tr> <tr> <td><a href="rfc7550.txt" class="t-db">RFC 7550</a></td> <td>Issues and Recommendations with Multiple Stateful DHCPv6 Options. O. Troan, B. Volz, M. Siodelski. May 2015. (Format: TXT=54206 bytes) (Updates RFC3315, RFC3633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7550) </td> </tr> <tr> <td><a href="rfc7552.txt" class="t-db">RFC 7552</a></td> <td>Updates to LDP for IPv6. R. Asati, C. Pignataro, K. Raza, V. Manral, R. Papneja. June 2015. (Format: TXT=48801 bytes) (Updates RFC5036, RFC6720) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7552)</td> </tr> <tr> <td><a href="rfc7561.txt" class="t-db">RFC 7561</a></td> <td>Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN. J. Kaippallimalil, R. Pazhyannur, P. Yegani. June 2015. (Format: TXT=50348 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7561) </td> </tr> <tr> <td><a href="rfc7563.txt" class="t-db">RFC 7563</a></td> <td>Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option. R. Pazhyannur, S. Speicher, S. Gundavelli, J. Korhonen, J. Kaippallimalil. June 2015. (Format: TXT=27982 bytes) (Updates RFC6757) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7563) </td> </tr> <tr> <td><a href="rfc7596.txt" class="t-db">RFC 7596</a></td> <td>Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture. Y. Cui, Q. Sun, M. Boucadair, T. Tsou, Y. Lee, I. Farrer. July 2015. (Format: TXT=47038 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7596) </td> </tr> <tr> <td><a href="rfc7597.txt" class="t-db">RFC 7597</a></td> <td>Mapping of Address and Port with Encapsulation (MAP-E). O. Troan, Ed., W. Dec, X. Li, C. Bao, S. Matsushima, T. Murakami, T. Taylor, Ed.. July 2015. (Format: TXT=70507 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7597) </td> </tr> <tr> <td><a href="rfc7598.txt" class="t-db">RFC 7598</a></td> <td>DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients. T. Mrugalski, O. Troan, I. Farrer, S. Perreault, W. Dec, C. Bao, L. Yeh, X. Deng. July 2015. (Format: TXT=40023 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7598) </td> </tr> <tr> <td><a href="rfc7599.txt" class="t-db">RFC 7599</a></td> <td>Mapping of Address and Port using Translation (MAP-T). X. Li, C. Bao, W. Dec, Ed., O. Troan, S. Matsushima, T. Murakami. July 2015. (Format: TXT=55548 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7599) </td> </tr> <tr> <td><a href="rfc7600.txt" class="t-db">RFC 7600</a></td> <td>IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd). R. Despres, S. Jiang, Ed., R. Penno, Y. Lee, G. Chen, M. Chen. July 2015. (Format: TXT=96462 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7600) </td> </tr> <tr> <td><a href="rfc7608.txt" class="t-db">RFC 7608</a></td> <td>IPv6 Prefix Length Recommendation for Forwarding. M. Boucadair, A. Petrescu, F. Baker. July 2015. (Format: TXT=10818 bytes) (Also BCP0198) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7608) </td> </tr> <tr> <td><a href="rfc7653.txt" class="t-db">RFC 7653</a></td> <td>DHCPv6 Active Leasequery. D. Raghuvanshi, K. Kinnear, D. Kukrety. October 2015. (Format: TXT=71631 bytes) (Updates RFC5460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7653) </td> </tr> <tr> <td><a href="rfc7668.txt" class="t-db">RFC 7668</a></td> <td>IPv6 over BLUETOOTH(R) Low Energy. J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. Shelby, C. Gomez. October 2015. (Format: TXT=52855 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7668) </td> </tr> <tr> <td><a href="rfc7676.txt" class="t-db">RFC 7676</a></td> <td>IPv6 Support for Generic Routing Encapsulation (GRE). C. Pignataro, R. Bonica, S. Krishnan. October 2015. (Format: TXT=21622 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7676) </td> </tr> <tr> <td><a href="rfc7678.txt" class="t-db">RFC 7678</a></td> <td>Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions. C. Zhou, T. Taylor, Q. Sun, M. Boucadair. October 2015. (Format: TXT=49074 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7678) </td> </tr> <tr> <td><a href="rfc7690.txt" class="t-db">RFC 7690</a></td> <td>Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)). M. Byerly, M. Hite, J. Jaeggli. January 2016. (Format: TXT=19061 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7690) </td> </tr> <tr> <td><a href="rfc7707.txt" class="t-db">RFC 7707</a></td> <td>Network Reconnaissance in IPv6 Networks. F. Gont, T. Chown. March 2016. (Format: TXT=88281 bytes) (Obsoletes RFC5157) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7707) </td> </tr> <tr> <tr> <td><a href="rfc7721.txt" class="t-db">RFC 7721</a></td> <td>Security and Privacy Considerations for IPv6 Address Generation Mechanisms. A. Cooper, F. Gont, D. Thaler. March 2016. (Format: TXT=43381 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7721) </td> </tr> <tr> <td><a href="rfc7755.txt" class="t-db">RFC 7755</a></td> <td>SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments. T. Anderson. February 2016. (Format: TXT=54648 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7755) </td> </tr> <tr> <td><a href="rfc7756.txt" class="t-db">RFC 7756</a></td> <td>Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode. T. Anderson, S. Steffann. February 2016. (Format: TXT=39291 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7756) </td> </tr> <tr> <td><a href="rfc7757.txt" class="t-db">RFC 7757</a></td> <td>Explicit Address Mappings for Stateless IP/ICMP Translation. T. Anderson, A. Leiva Popper. February 2016. (Format: TXT=40938 bytes) (Updates RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7757) </td> </tr> <tr> <td><a href="rfc7775.txt" class="t-db">RFC 7775</a></td> <td>IS-IS Route Preference for Extended IP and IPv6 Reachability. L. Ginsberg, S. Litkowski, S. Previdi. February 2016. (Format: TXT=23624 bytes) (Updates RFC5308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7775) </td> </tr> <tr> <td><a href="rfc7794.txt" class="t-db">RFC 7794</a></td> <td>IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability. L. Ginsberg, Ed., B. Decraene, S. Previdi, X. Xu, U. Chunduri. March 2016. (Format: TXT=15925 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7794) </td> </tr> <tr> <td><a href="rfc7837.txt" class="t-db">RFC 7837</a></td> <td>IPv6 Destination Option for Congestion Exposure (ConEx). S. Krishnan, M. Kuehlewind, B. Briscoe, C. Ralli. May 2016. (Format: TXT=29708 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7837) </td> </tr> <tr> <td><a href="rfc7849.txt" class="t-db">RFC 7849</a></td> <td>An IPv6 Profile for 3GPP Mobile Devices. D. Binet, M. Boucadair, A. Vizdal, G. Chen, N. Heatley, R. Chandler, D. Michaud, D. Lopez, W. Haeffner. May 2016. (Format: TXT=51725 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7849) </td> </tr> <tr> <td><a href="rfc7864.txt" class="t-db">RFC 7864</a></td> <td>Proxy Mobile IPv6 Extensions to Support Flow Mobility. CJ. Bernardos, Ed.. May 2016. (Format: TXT=44225 bytes) (Updates RFC5213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7864) </td> </tr> <tr> <td><a href="rfc7872.txt" class="t-db">RFC 7872</a></td> <td>Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World. F. Gont, J. Linkova, T. Chown, W. Liu. June 2016. (Format: TXT=30924 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7872) </td> </tr> <tr> <td><a href="rfc7934.txt" class="t-db">RFC 7934</a></td> <td>Host Address Availability Recommendations. L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. July 2016. (Format: TXT=37124 bytes) (Also BCP0204) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7934) </td> </tr> <tr> <td><a href="rfc7973.txt" class="t-db">RFC 7973</a></td> <td>Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation. R. Droms, P. Duffy. November 2016. (Format: TXT=8208 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7973) </td> </tr> <tr> <td><a href="rfc8021.txt" class="t-db">RFC 8021</a></td> <td>Generation of IPv6 Atomic Fragments Considered Harmful. F. Gont, W. Liu, T. Anderson. January 2017. (Format: TXT=25686 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8021) </td> </tr> <tr> <td><a href="rfc8025.txt" class="t-db">RFC 8025</a></td> <td>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch. P. Thubert, Ed., R. Cragie. November 2016. (Format: TXT=16342 bytes) (Updates RFC4944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8025) </td> </tr> <tr> <td><a href="rfc8043.txt" class="t-db">RFC 8043</a></td> <td>Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space. B. Sarikaya, M. Boucadair. January 2017. (Format: TXT=35213 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8043) </td> </tr> <tr> <td><a href="rfc8064.txt" class="t-db">RFC 8064</a></td> <td>Recommendation on Stable IPv6 Interface Identifiers. F. Gont, A. Cooper, D. Thaler, W. Liu. February 2017. (Format: TXT=19179 bytes) (Updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, RFC5121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8064) </td> </tr> <tr> <td><a href="rfc8065.txt" class="t-db">RFC 8065</a></td> <td>Privacy Considerations for IPv6 Adaptation-Layer Mechanisms. D. Thaler. February 2017. (Format: TXT=22718 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8065) </td> </tr> <tr> <td><a href="rfc8066.txt" class="t-db">RFC 8066</a></td> <td>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines. S. Chakrabarti, G. Montenegro, R. Droms, J. Woodyatt. February 2017. (Format: TXT=17494 bytes) (Updates RFC4944, RFC6282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8066) </td> </tr> <tr> <td><a href="rfc8096.txt" class="t-db">RFC 8096</a></td> <td>The IPv6-Specific MIB Modules Are Obsolete. B. Fenner. April 2017. (Format: TXT=117298 bytes) (Obsoletes RFC2452, RFC2454, RFC2465, RFC2466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8096) </td> </tr> <tr> <td><a href="rfc8105.txt" class="t-db">RFC 8105</a></td> <td>Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE). P. Mariager, J. Petersen, Ed., Z. Shelby, M. Van de Logt, D. Barthel. May 2017. (Format: TXT=49537 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8105) </td> </tr> <tr> <td><a href="rfc8106.txt" class="t-db">RFC 8106</a></td> <td>IPv6 Router Advertisement Options for DNS Configuration. J. Jeong, S. Park, L. Beloeil, S. Madanapalli. March 2017. (Format: TXT=43092 bytes) (Obsoletes RFC6106) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8106) </td> </tr> <tr> <td><a href="rfc8114.txt" class="t-db">RFC 8114</a></td> <td>Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network. M. Boucadair, C. Qin, C. Jacquenet, Y. Lee, Q. Wang. March 2017. (Format: TXT=47896 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8114) </td> </tr> <tr> <td><a href="rfc8115.txt" class="t-db">RFC 8115</a></td> <td>DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes. M. Boucadair, J. Qin, T. Tsou, X. Deng. March 2017. (Format: TXT=17386 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8115) </td> </tr> <tr> <td><a href="rfc8138.txt" class="t-db">RFC 8138</a></td> <td>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header. P. Thubert, Ed., C. Bormann, L. Toutain, R. Cragie. April 2017. (Format: TXT=81825 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8138) </td> </tr> <tr> <td><a href="rfc8159.txt" class="t-db">RFC 8159</a></td> <td>Keyed IPv6 Tunnel. M. Konstantynowicz, Ed., G. Heron, Ed., R. Schatzmayr, W. Henderickx. May 2017. (Format: TXT=27302 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8159) </td> </tr> <tr> <td><a href="rfc8163.txt" class="t-db">RFC 8163</a></td> <td>Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks. K. Lynn, Ed., J. Martocci, C. Neilson, S. Donaldson. May 2017. (Format: TXT=55845 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8163) </td> </tr> <tr> <td><a href="rfc8191.txt" class="t-db">RFC 8191</a></td> <td>Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6). Z. Yan, J. Lee, X. Lee. August 2017. (Format: TXT=20719 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8191) </td> </tr> <tr> <td><a href="rfc8200.txt" class="t-db">RFC 8200</a></td> <td>Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. July 2017. (Format: TXT=93658 bytes) (Obsoletes RFC2460) (Also STD0086) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8200) </td> </tr> <tr> <td><a href="rfc8201.txt" class="t-db">RFC 8201</a></td> <td>Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. Mogul, R. Hinden, Ed.. July 2017. (Format: TXT=42751 bytes) (Obsoletes RFC1981) (Also STD0087) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8201) </td> </tr> <tr> <td><a href="rfc8215.txt" class="t-db">RFC 8215</a></td> <td>Local-Use IPv4/IPv6 Translation Prefix. T. Anderson. August 2017. (Format: TXT=14846 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8215) </td> </tr> <tr> <td><a href="rfc8219.txt" class="t-db">RFC 8219</a></td> <td>Benchmarking Methodology for IPv6 Transition Technologies. M. Georgescu, L. Pislaru, G. Lencse. August 2017. (Format: TXT=66085 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8219) </td> </tr> <tr> <td><a href="rfc8250.txt" class="t-db">RFC 8250</a></td> <td>IPv6 Performance and Diagnostic Metrics (PDM) Destination Option. N. Elkins, R. Hamilton, M. Ackermann. September 2017. (Format: TXT=65231 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8250) </td> </tr> <tr> <td><a href="rfc8273.txt" class="t-db">RFC 8273</a></td> <td>Unique IPv6 Prefix per Host. J. Brzozowski, G. Van de Velde. December 2017. (Format: TXT=22867 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8273) </td> </tr> <tr> <td><a href="rfc8354.txt" class="t-db">RFC 8354</a></td> <td>Use Cases for IPv6 Source Packet Routing in Networking (SPRING). J. Brzozowski, J. Leddy, C. Filsfils, R. Maglione, Ed., M. Townsley. March 2018. (Format: TXT=18271 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8354) </td> </tr> <tr> <td><a href="rfc8369.txt" class="t-db">RFC 8369</a></td> <td>Internationalizing IPv6 Using 128-Bit Unicode. H. Kaplan. 1 April 2018. (Format: TXT=24429 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8369) </td> </tr> <tr> <td><a href="rfc8371.txt" class="t-db">RFC 8371</a></td> <td>Mobile Node Identifier Types for MIPv6. C. Perkins, V. Devarapalli. July 2018. (Format: TXT=34580 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8371) </td> </tr> <tr> <td><a href="rfc8585.txt" class="t-db">RFC 8585</a></td> <td>Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service. J. Palet Martinez, H. M.-H. Liu, M. Kawashima. May 2019. (Format: TXT=49405, HTML=0 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8585) </td> </tr> </table> <p><a href="#contents"><img class="i-u" src="../../../images/go_up.gif" alt="Up Arrow"></a></p> <hr> <p class="p-m-n"><br>Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or <a href="javascript:mailus('info-support','zytrax.com','Support Issue')" class="t-db">info-support at zytrax</a>. You will have a warm inner glow for the rest of the day.</p> <!-- end body table --> </div> <div class="l-l"> <!-- left hand navigation --> <div class="n-l"> <p class="c-g t-b t-o m-h5 t-r">Tech Stuff</p> <!-- first row of navigation CSS format --> <ul class="n-l1p"> <li class="n-l1p-e"> <a href="http://www.zytrax.com/tech" class="n-l-c">tech home</a> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="Digital Audio - primers, calculators, equalization, frequency tables, file formats, glossary - a mere splash in the ocean" href="http://www.zytrax.com/tech/audio/" class="n-l-c">audio stuff</a> <ul class="n-l2"> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/audio/sound.html" class="n-l-f">sound primer</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/audio/digital-sound.html" class="n-l-f">digital primer</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/audio/audio.html" class="n-l-f">note frequencies</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/audio/equalization.html" class="n-l-f">eq, meters & fft</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/audio/calculator.html" class="n-l-f">calculators</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/audio/formats.html" class="n-l-f">files & codecs</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/audio/glossary.html" class="n-l-f">glossary</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="Browser IDs, SSIs, Apache Configuration, regular expressions" href="http://www.zytrax.com/tech/web/" class="n-l-c">web stuff</a> <ul class="n-l2"> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/web/browser_ids.htm" class="n-l-f">browser ids</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/web/mobile_ids.html" class="n-l-f">mobile_ids</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/web/env_var.htm" class="n-l-f">apache env vars</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/web/ssi.htm" class="n-l-f">apache ssi</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/css/workarounds.html#popout" class="n-l-f">css popout menus</a></li> <li class="n-l2-e"><a title="most of those annoying HTML entity codes that we forget all the time" href="http://www.zytrax.com/tech/web/entities.html" class="n-l-f">html entities</a></li> <li class="n-l2-e"><a title="Decimal to Hexidecimal to Binary conversion - even Octal!" href="http://www.zytrax.com/tech/protocols/hex.html" class="n-l-f">dec > hex > bin</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a href="http://www.zytrax.com/tech/dom/" class="n-l-c">dom stuff</a><br> <ul class="n-l2"> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/dom/guide.html" class="n-l-f">dom guide</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/dom/w3c_dom.html" class="n-l-f">page explorer</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/dom/navigate.html" class="n-l-f">dom navigation</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="CSS is about a lot more than STYLE. Wheezes, table-less layouts, CSS pop-ups, CSS Shortcuts" href="http://www.zytrax.com/tech/css/" class="n-l-c">css stuff</a> <ul class="n-l2"> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/css/layoutnotes.html" class="n-l-f">css liquid design</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/css/workarounds.html#popout" class="n-l-f">css popout menus</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/css/workarounds.html" class="n-l-f">css notes</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/css/syntax.html" class="n-l-f">css syntax</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/css/shortcut.html" class="n-l-f">css short-forms</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="includes PHP, Ruby and some Java stuff (all about obscure solutions to stupid problems)" href="http://www.zytrax.com/tech/lang/" class="n-l-c">language stuff</a> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="quick overview 'cos we always forget - not that we ever knew much - now includes a nifty browser-based tester" href="http://www.zytrax.com/tech/web/regex.htm" class="n-l-c">regex stuff</a> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="rfc ordered by subject" href="http://www.zytrax.com/tech/rfcs/" class="n-l-c">rfc stuff</a> <ul class="n-l2"> <li title="dns rfcs" class="n-l2-e"><a href="http://www.zytrax.com/books/dns/apd/" class="n-l-f">dns rfcs</a></li> <li title="ldap rfcs" class="n-l2-e"><a href="http://www.zytrax.com/books/ldap/apc/" class="n-l-f">ldap rfcs</a></li> <li title="ipv6 rfcs" class="n-l2-e"><a href="http://www.zytrax.com/tech/protocols/ipv6.html#rfcs" class="n-l-f">ipv6 rfcs</a></li> <li title="tls/x.509 rfcs" class="n-l2-e"><a href="http://www.zytrax.com/tech/survival/ssl.html#rfcs" class="n-l-f">tls/x.509 rfcs</a></li> <li title="some other subjects - we only update these when we are active - some lists are consequently long in the tooth" class="n-l2-e"><a href="http://www.zytrax.com/tech/rfcs" class="n-l-f">other rfcs</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="TCP/IP, IPv4, IPv6, ISDN, LAN, VoIP, ITU Multi-Media" href="http://www.zytrax.com/tech/protocols/" class="n-l-c">protocol stuff</a> <ul class="n-l2"> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/protocols/tcp.html" class="n-l-f">tcp, udp, icmp</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/protocols/ip-classes.html" class="n-l-f">ipv4</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/protocols/ipv6.html" class="n-l-f">ipv6</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/protocols/isdn/" class="n-l-f">isdn</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/survival/ssl.html" class="n-l-f">ssl/tls/x.509</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/ss7/" class="n-l-f">ss7 &sigtran</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/protocols/lan/" class="n-l-f">802.3 lan</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="PC Parallel Ports, LAN wiring, RS232, Centronics, DIN" href="http://www.zytrax.com/tech/layer_1/" class="n-l-c">cable stuff</a> <ul class="n-l2"> <li title="10baseT, 100base-TX/T4, 1000baseT, 10Gbase-T, RJ45, STP" class="n-l2-e"><a href="http://www.zytrax.com/tech/layer_1/cables/tech_lan.htm" class="n-l-f">lan pinouts</a></li> <li title="mixing telephony and 802.3 LAN can be done on cat5/5e/6 wiring" class="n-l2-e"><a href="http://www.zytrax.com/tech/layer_1/mixed.html" class="n-l-f">lan & telephone</a></li> <li title="RS 232 pinouts on db9, db24 and T1" class="n-l2-e"><a href="http://www.zytrax.com/tech/layer_1/cables/tech_rs232.htm" class="n-l-f">rs232 pinouts</a></li> <li class="n-l2-e"><a href="http://www.zytrax.com/tech/layer_1/cables/heavy.htm" class="n-l-f">serial primer</a></li> <li title="USB 2.0, 3.0, 3.1 and 3.2 plus Firewire (i.Link) IEE 1394" class="n-l2-e"><a href="http://www.zytrax.com/tech/pc/serial.html" class="n-l-f">usb & firewire</a></li> <li title="some information about display and monitors/console interfaces inclusing VGA, HDMI, DVI and Thunderbolt" class="n-l2-e"><a href="http://www.zytrax.com/tech/pc/monitors.htm" class="n-l-f">displays</a></li> <li title="modular jack is the term we should use for those telephone and lan connectors" class="n-l2-e"><a href="http://www.zytrax.com/tech/layer_1/cables/cables_jacks.htm" class="n-l-f">modular jacks</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="10baseT, 100base-TX/T4, 1000baseT, 10Gbase-T, RJ45, STP" href="http://www.zytrax.com/tech/layer_1/cables/tech_lan.htm" class="n-l-c">lan wiring</a> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="DB9, DB25 pinouts, RJ45 serial, T1 and RS standards alphabet soup" href="http://www.zytrax.com/tech/layer_1/cables/tech_rs232.htm" class="n-l-c">rs232 wiring</a> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="Decimal to Hex and Binary conversion table - even a description of Octal!" href="http://www.zytrax.com/tech/protocols/hex.html" class="n-l-c">dec > hex > bin</a> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="character sets ain't as simple as they look" href="http://www.zytrax.com/tech/codes.htm" class="n-l-c">character sets</a> <ul class="n-l2"> <li title="pretty much all the characters sets in the known universe including utf-7, 8 and 16" class="n-l2-e"><a href="http://www.zytrax.com/tech/characters/" class="n-l-f">character sets</a></li> <li title="ascii variant of international reference alphabet 5 (ira5)" class="n-l2-e"><a href="http://www.zytrax.com/tech/codes.htm" class="n-l-f">ascii codes</a></li> <li title="international reference alphabet 5 (ascii's cousin)" class="n-l2-e"><a href="http://www.zytrax.com/tech/ia5.html" class="n-l-f">ia5 codes</a></li> <li title="all that ™ & © stuff" class="n-l2-e"><a href="http://www.zytrax.com/tech/web/entities.html" class="n-l-f">html entities</a></li> <li title="silly page containing a bunch of fonts in various sizes including your PCs defaults" class="n-l2-e"><a href="http://www.zytrax.com/tech/web/fonts.html" class="n-l-f">web fonts</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="The T series, E series and J series and then all that optical stuff (OC-12 etc.)" href="http://www.zytrax.com/tech/data_rates.htm" class="n-l-c">data rate stuff</a> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="Even us electronic guys gotta know how to screw it together, if you get our drift" href="http://www.zytrax.com/tech/mech/" class="n-l-c">mechanical stuff</a> <ul class="n-l2"> <li title="fastener (screw) head styles - surprising number of choices" class="n-l2-e"><a href="http://www.zytrax.com/tech/mech/heads.htm" class="n-l-f">head styles</a></li> <li title="threads for imperial (UNF, UNC) & metric sizes" class="n-l2-e"><a href="http://www.zytrax.com/tech/mech/threads.htm" class="n-l-f">threads</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="A collection of howtos including Samba3 as PDC, FreeBSD firewalls" href="http://www.zytrax.com/tech/howtos/" class="n-l-c">howto stuff</a> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="A collection of survival guides - quick overviews - to popular software" href="http://www.zytrax.com/tech/survival/" class="n-l-c">survival stuff</a> <ul class="n-l2"> <li title="tls and x.509 (ssl) certificates - warning: headache inducing stuff" class="n-l2-e"><a href="http://www.zytrax.com/tech/survival/ssl.html" class="n-l-f">ssl/tls/x.509</a></li> <li title="Abstract Syntax Notation. 1 (ASN.!) and Distinguished Encoding Rules (DER) - not for the faint hearted. Pass the pain medication, we feel a headache coming on." class="n-l2-e"><a href="http://www.zytrax.com/tech/survival/asn1.html" class="n-l-f">ASN.1 & DER</a></li> <li title="Kerberos is great - but tough, oh my, tough stuff" class="n-l2-e"><a href="http://www.zytrax.com/tech/survival/kerberos.html" class="n-l-f">kerberos</a></li> <li title="We've used postfix for years but always forget which of the 27 million parameters to use" class="n-l2-e"><a href="http://www.zytrax.com/tech/survival/postfix.html" class="n-l-f">postfix</a></li> <li title="Symetric, asymetric, MACs, hashes - eye watering stuff" class="n-l2-e"><a href="http://www.zytrax.com/tech/survival/encryption.html" class="n-l-f">encryption</a></li> <li title="Just what time is it in Kuala Lumpur, and what's that got to do with cron?" class="n-l2-e"><a href="http://www.zytrax.com/tech/survival/cron.html" class="t-db">cron</a></li> <li title="Gotta love wxWidgets - free, fantastic, flexible - but hard to see the wood for the trees sometimes" class="n-l2-e"><a href="http://www.zytrax.com/tech/survival/wxwidgets.html" class="n-l-f">wxWidgets</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="Our wireless overview, Calculators, Fresnel zones, links to 'heavy' stuff, some early 802.11 stuff (mostly wi-fi related)" href="http://www.zytrax.com/tech/wireless/" class="n-l-c">wireless stuff</a> <ul class="n-l2"> <li title="our irreverent general intro to wirelss - purist will not like this page" class="n-l2-e"><a href="http://www.zytrax.com/tech/wireless/intro.htm" class="n-l-f">overview</a></li> <li title="wireless calculators for system budgets, free-space loss, fresnel effects and a bunch of other stuff" class="n-l2-e"><a href="http://www.zytrax.com/tech/wireless/calc.htm" class="n-l-f">calculators</a></li> <li title="fresnel effect explanation - well, we can understand it" class="n-l2-e"><a href="http://www.zytrax.com/tech/wireless/fresnel.htm" class="n-l-f">fresnel effects</a></li> <li title="our outrageously biased description of frequency hopping versus direct sequence for spread spectrum" class="n-l2-e"><a href="http://www.zytrax.com/tech/wireless/fh_ds.htm" class="n-l-f">fh vs ds</a></li> <li title="some terminology covering 802 standards and modulation techniques" class="n-l2-e"><a href="http://www.zytrax.com/tech/wireless/soup.html" class="n-l-f">wireless soup</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="Pinouts - USB, DIN, Firewire, VGA, DVI, HDMI, DisplayPort and Thunderbolt, I/O interface speeds, Screen sizes including HD" href="http://www.zytrax.com/tech/pc/" class="n-l-c">pc stuff</a> <ul class="n-l2"> <li title="din and mini-din for older PCs" class="n-l2-e"><a href="http://www.zytrax.com/tech/pc/din.htm" class="n-l-f">din & mini-din</a></li> <li title="802.3 LAN stuff" class="n-l2-e"><a href="http://www.zytrax.com/tech/layer_1/cables/tech_lan.htm" class="n-l-f">802.3 lan</a></li> <li title="connection of monitors has changed over the years from clunky VGA to svelte HDMI - all the pinouts you could hope for" class="n-l2-e"><a href="http://www.zytrax.com/tech/pc/monitors.htm" class="n-l-f">monitor pinouts</a></li> <li title="serial (db9, db24) connections - slow but trusty" class="n-l2-e"><a href="http://www.zytrax.com/tech/layer_1/cables/tech_rs232.htm" class="n-l-f">serial stuff</a></li> <li title="usb pinouts and descriptions of power levels for usb 1, 2 and 3 - also includes firewire" class="n-l2-e"><a href="http://www.zytrax.com/tech/pc/serial.html" class="n-l-f">usb & firewire</a></li> <li title="pc interfaces are changing and getting faster - we can never keep up - list of interfaces and their speeds" class="n-l2-e"><a href="http://www.zytrax.com/tech/pc/interfaces.html" class="n-l-f">pc interfaces</a></li> <li title="we get confused about most things - just what is 1080p - pc and tv screen resolution table with some explanations" class="n-l2-e"><a href="http://www.zytrax.com/tech/pc/resolution.html" class="n-l-f">screen resolutions</a></li> </ul> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="Electronic glossary, some old experiments with 3.3/5V protection and early BGA designs" href="http://www.zytrax.com/tech/electronics/" class="n-l-c">electronic stuff</a> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="ragbag collection of links that we publish from time to time - maybe useful, maybe not" href="http://www.zytrax.com/links" class="n-l-c">tech links</a> </li> </ul> <ul class="n-l1p"> <li class="n-l1p-e"> <a title="Our DNS and LDAP for Rocket Scientists guides" href="http://www.zytrax.com/books" class="n-l-c">open guides</a> <ul class="n-l2"> <li title="dns for rocket scientists" class="n-l2-e"><a href="http://www.zytrax.com/books/dns/" class="n-l-f">dns guide</a></li> <li title="ldap for rocket scientists" class="n-l2-e"><a href="http://www.zytrax.com/books/ldap/" class="n-l-f">ldap guide</a></li> </ul> </li> </ul> <p class="t-r"> <a title="RSS (2.0) Feed - right click on icon, select 'Copy Link URL' or 'Copy Shortcut', paste into RSS Feed Reader, or drag and drop into RSS Feed Reader" href="http://www.zytrax.com/zytrax.rss" class="n-l-c"><img class="w-32 center" src="http://www.zytrax.com/images/rss.png" alt="RSS Feed Icon"></a> </p> <p class="p-b-h t-r">If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C standards compliant browser such as <a href="http://www.mozilla.org" class="t-db">Firefox</a></p> </div> </div> <div class="l-r"> <!-- right menu --> <div class="w-150"> <!-- SiteSearch Google --> <p class="c-g t-b t-o m-h8">Search</p> <form class="f-b-n" method="get" action="http://www.google.com/custom" target="_top"> <table> <tr> <td style="white-space: nowrap"> <input type="hidden" name="domains" value="www.zytrax.com"> <input class="b-lg" type="text" name="q" size="16" maxlength="255" value=""> </td></tr> <tr> <td style="white-space: nowrap"> <table> <tr> <td> <input type="radio" name="sitesearch" value="" checked="checked"><span class="t-s">web</span> </td> <td> <input type="radio" name="sitesearch" value="www.zytrax.com" ><span class="t-s">zytrax.com</span> </td> </tr> </table> <input class="b-lg" type="submit" name="sa" value="Google Search"> <input type="hidden" name="client" value="pub-9419480011552853"> <input type="hidden" name="forid" value="1"> <input type="hidden" name="ie" value="ISO-8859-1"> <input type="hidden" name="oe" value="ISO-8859-1"> <input type="hidden" name="safe" value="active"> <input type="hidden" name="cof" value="GALT:#008000;GL:1;DIV:#336699;VLC:663399;AH:center;BGC:FFFFFF;LBGC:336699;ALC:0000FF;LC:0000FF;T:000000;GFNT:0000FF;GIMP:0000FF;LH:50;LW:355;L:http://www.zytrax.com/images/zytrax-info-google.gif;S:http://www.zytrax.com/tech;FORID:1;"> <input type="hidden" name="hl" value="en"> </td></tr></table> </form> <!-- SiteSearch Google --> <!-- share page feature --> <div class="t-h"><p><span class="t-g">Share</span></p> <div class="t-h-1"> Icons made by <a href="https://www.flaticon.com/authors/icomoon" title="Icomoon">Icomoon</a> from <a href="https://www.flaticon.com/" title="Flaticon">www.flaticon.com</a> is licensed by <a href="http://creativecommons.org/licenses/by/3.0/" title="Creative Commons BY 3.0" target="_blank">CC 3.0 BY</a></div></div> <a href="http://www.facebook.com/share.php?u=http://www.zytrax.com/tech/protocols/ipv6.html&h=Tech%20Stuff%20-%20IPv6"><img class="w-32" title="add page to facebook" src="http://www.zytrax.com/images/facebook.png" alt="share page via facebook"></a> <a href="http://twitter.com/home/?status=Useful%20page%20http://www.zytrax.com/tech/protocols/ipv6.html"><img class="w-32" title="tweet this page" src="http://www.zytrax.com/images/twitter.png" alt="tweet this page"></a> <p class="c-g t-b t-o m-h5">Page<p> <a class="a-n" href="http://www.zytrax.com/feedback.htm"><img class="w-32" title="Page comment feature" src="http://www.zytrax.com/images/mail.png" alt="email us"></a> <a class="a-n" href="http://www.zytrax.com/run/mailpage.php"><img class="w-32" title="Send to a friend" src="http://www.zytrax.com/images/mailfriend.png" alt="Send to a friend feature"></a> <a class="a-n" href="#" onclick="window.print();return false;"><img class="w-32" title="print page" src="http://www.zytrax.com/images/printpage.png" alt="print this page"></a> <a class="a-n" title="View page full width - suppresses left and right hand menus" href="http://www.zytrax.com/tech/protocols/ipv6.html?pf=yes"><img class="w-32" src="http://www.zytrax.com/images/fullwidth.png" alt="Display full width page"></a> <a class="a-n" href="#" onclick="fontchange('d');return false;"><img class="w-32" title="Decrease font size" src="http://www.zytrax.com/images/smaller.png" alt="Decrease font size"></a> <a class="a-n" href="#" onclick="fontchange('i');return false;"><img class="w-32" title="Increase font size" src="http://www.zytrax.com/images/bigger.png" alt="Increase font size"></a> <p class="c-g t-b t-o m-h5">Standards</p> <p> <a href="http://www.iso.org" title="International Standards Organisation" target="_blank" class="w-db">ISO (International)</a><br> <a href="http://www.iec.ch" title="International Electrotechnical Commission" target="_blank" >IEC (International)</a><br> <a href="http://www.ansi.org" target="_blank" class="w-db">ANSI (US)</a><br> <a href="http://www.din.de/en" target="_blank" class="w-db">DIN (Germany)</a><br> <a href="http://www.etsi.org/" target="_blank" class="w-db">ETSI (EU)</a><br> <a href="http://www.bsigroup.com/en-GB" target="_blank" class="w-db">BSI (UK)</a><br> <a href="http://www.afnor.org/en" target="_blank" class="w-db">AFNOR (France)</a><br> </p> <p class="c-g t-b t-o m-h5">Telecom</p> <p> <a href="http://www.tiaonline.org" title="RS232 etc" target="_blank" class="w-db">TIA (US)</a><br> <a href="http://www.ecianow.org" target="_blank" class="w-db">ECIA (US)</a><br> <a href="http://www.itu.int" target="_blank" class="w-db">ITU (International)</a><br> <a href="http://www.ieee.org" target="_blank" class="w-db">IEEE (US)</a><br> <a href="http://www.etsi.org/" target="_blank" class="w-db">ETSI (EU)</a><br> <a href="http://www.ofcom.gov.uk/" target="_blank" class="w-db">OFCOM (UK)</a><br> </p> <p class="c-g t-b t-o m-h5">Internet</p> <p> <a href="http://www.ietf.org/" target="_blank" class="w-db">IETF</a><br> <a href="http://www.ietf.org/rfc.html" target="_blank" class="w-db">IETF-RFCs</a><br> <a href="http://www.iana.org/" target="_blank" class="w-db">IANA</a><br> <a href="http://www.icann.org/" target="_blank" class="w-db">ICANN</a><br> <a href="http://www.w3c.org/" target="_blank" class="w-db">W3C</a><br> </p> <p class="c-g t-b t-o m-h5">Electronics</p> <p> <a href="http://www.jedec.org" title="chip pacakaging, testing etc." target="_blank" class="w-db">JEDEC</a><br> <a href="http://www.ecianow.org" target="_blank" class="w-db">ECIA (US)</a><br> </p> </div> <p class="c-g t-b t-o">Site</p> <a class="a-n" href="http://www.zytrax.com/about_site.htm#css"><img class="w-32" src="http://www.zytrax.com/images/css.png" alt="CSS Technology"></a> <a class="a-n" href="http://www.zytrax.com/security/spf.html"><img title="SPF Record Conformant Domain" class="w-32" src="http://www.zytrax.com/images/spf.png" alt="SPF Record Conformant Domain"></a> </div> <div class="l-f"> <!-- standard footer full width --> <table> <tr> <td class="p-f-s t-l"> Copyright © 1994 - 2024 ZyTrax, Inc.<br> All rights reserved. <a href="http://www.zytrax.com/legal.html" class="p-f-s">Legal</a> and <a href="http://www.zytrax.com/privacy.html" class="p-f-s">Privacy</a> </td> <td class="t-c"><a href="https://www.zytrax.com" target="_blank" class="p-f-s">site by zytrax</a><br> <a href="https://www.javapipe.com" target="_blank" class="p-f-s">hosted by javapipe.com</a></td> <td class="p-f-s t-r"> <a href="javascript:mailus('web-master','zytrax.com','About Web site')" class="p-f-s">web-master at zytrax</a><br> Page modified: May 24 2023. </td> </tr> </table> </div> <!-- pop-out tables only if Javascript supported --> <!-- only css menus --> </body> </html>