ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

IPV6 TUTORIAL SESSION
SUNDAY, 3 DECEMBER 2006
ICANN MEETING
SÃO PAULO, BRAZIL

>>JORDI PALET: HI, EVERYONE.

I THINK WE SHOULD START.

OTHERWISE, WE'LL PROBABLY BECOME A LITTLE BIT LATE.

IS THE SOUND OKAY?

YEAH, OKAY.

SO I AM JORDI PALET.

I AM GOING TO DO THE FIRST PART OF THIS WORKSHOP.

THEN CHRISTIAN O'FLAHERTY, WHO IS THE CHAIR OF THE POLICY WORKING GROUP IN LACNIC -- I THINK THERE IS SOME PROBLEM WITH THE AUDIO.

OKAY.

NO, I THINK STILL THERE IS SOMETHING.

OKAY.

SO, AGAIN, I AM JORDI PALET.

WE HAVE BEEN WAITING A LITTLE BIT TO SEE IF MORE PEOPLE JOIN US.

BUT WE CANNOT FINISH LATE, SO WE REALLY SHOULD START NOW.

I AM GOING TO DO THE FIRST PART OF THIS WORKSHOP, WHICH -- AN INTRODUCTION TO IPV6, NOT EXTREMELY TECHNICAL, SO EVEN PEOPLE WHO DO NOT HAVE I.P. KNOWLEDGE CAN GET AN IDEA ABOUT WHAT WE ARE TALKING ABOUT.

THEN NEXT TO ME, CHRISTIAN O'FLAHERTY, WHO IS THE CHAIR OF THE POLICY WORKING GROUP IN LACNIC, WILL DO A REVIEW OF THE STATUS OF IPV6 POLICIES AT DIFFERENT REGISTRY SERVICE REGIONS.

AND THEN WE WILL HAVE AN OPEN DEBATE, WHICH THE MAIN TOPIC WILL BE IPV6 AS AN INNOVATION OPPORTUNITY FOR DEVELOPING COUNTRIES WHERE ALSO WILL PARTICIPATE SEBASTIAN BELLAGAMBA, WHO IS THE CHAIR OF THE ASO AC.

I THINK THE FIRST PART WILL TAKE SOMETHING LESS THAN ONE HOUR.

WE'LL HAVE SOME TIME FOR QUESTIONS I'M NOT SURE YET -- THERE IS A MIKE OVER THERE.

SO IF YOU HAVE QUESTIONS AT ANY TIME, JUST GO TO THE MIKE.

AND THEN I THINK WE WILL DO THE NEXT PART IN MORE OR LESS HALF AN HOUR EACH, PROBABLY A LITTLE BIT LESS.

OKAY?

SO LET ME SET UP THE SLIDES.

EVERYTHING SHOULD BE OKAY.

RIGHT.

OKAY.

SO THE FIRST QUESTION WHEN WE START TALKING ABOUT IPV6 IS WHY WE HAVE A NEED FOR A NEW I.P. PROTOCOL.

AS YOU KNOW FOR SURE, I.P.'S THE INTERNET PROTOCOL, WHICH IS THE ONE USED TO TRANSPORT ALL THE INFORMATION THAT TODAY IS RUNNING ACROSS INTERNET.

SO THE MAIN REASON WHY WE STARTED LOOKING AT A NEW VERSION, WHICH, IN FACT, AT THE BEGINNING OF THE DEVELOPMENT, IT WAS CALLED IPNG, WHICH STANDS FOR I.P. NEXT GENERATION, WAS, BASICALLY, WE STARTED TO FORESEE THE NEED FOR MANY MORE ADDRESSES.

SO WHY WE NEEDED MORE ADDRESSES?

WELL, AT THAT TIME, WE WERE ONLY CONNECTING PCS TO INTERNET, COMPUTERS.

BUT WE ALREADY DISCOVERED THAT OTHER KIND OF DEVICES, LIKE CELLULAR PHONES, PDAS, ALL KIND OF APPLIANCES, EVEN CARS, REALLY NEED INTERNET ADDRESSES IN ORDER TO TAKE ADVANTAGE OF USING INTERNET FOR ALL KIND OF COMMUNICATIONS.

SO PROBABLY MOST OF YOU KNOW THAT ALREADY IF YOU HAVE A CELLULAR PHONE WHICH IS, LET'S SAY, NOT OLDER THAN TWO OR THREE YEARS, IT HAS ALREADY INTERNET PROTOCOL.

AND, IN FACT, IT HAS ALREADY TYPICALLY SUPPORT FOR BOTH IPV4 AND IPV6.

I CAN TALK ABOUT OTHER EXAMPLES LIKE THE FAMOUS FREEZER CONNECTED TO INTERNET.

YEAH, IT SEEMS IT'S KIND OF LUXURY, BUT WE CAN THINK IN NOT JUST THE FREEZER, BUT ANY KIND OF APPLIANCE IN THE HOME OR IN THE OFFICE, NOT JUST TO MAKE OUR LIFE MORE COMFORTABLE, BUT ALSO IN ORDER TO, FOR EXAMPLE, OFFER SERVICES FOR PREVENTIVE MAINTENANCE, SO WE CAN HAVE ISPS OR THE MANUFACTURER OF THE FREEZER OR ANY KIND OF APPLIANCE OR THIRD-PARTY COMPANIES OFFERING SERVICES TO IN ADVANCE THE FREEZER IS GOING TO BLOW UP AND YOU WILL LOSE ALL THE FOOD, WHICH HAPPENED, ACTUALLY, TO ME WHEN I WAS TRAVELING, YOU WILL BE ADVISED THAT, HEY, THERE IS A COMPONENT THAT IS GOING TO FAIL.

REPLACE IT, BECAUSE IT'S GOING TO BE TOTALLY BROKEN IN, LET'S SAY, TWO WEEKS OR SOMETHING LIKE THAT.

THAT'S VERY PRACTICAL EXAMPLES.

AND THERE ARE MANY MORE, LIKE SURVEILLANCE, ALL KIND OF REMOTE CONTROL AND SO ON.

I HAVE A VERY GOOD EXAMPLE ALSO FOR THE CARS.

THERE IS AN ASSOCIATION WHICH IS CALLED CAR-TO-CAR COMMUNICATION ASSOCIATION, WHICH WAS FOUNDED SOMETHING LIKE THREE YEARS AGO.

AND THEY DECIDED TO USE IPV6 FOR ALL THE COMMUNICATIONS NOT JUST INSIDE THE CAR, BUT ALSO TO CONNECT CARS FOR INFORMATION SYSTEMS, BUT, IN ADDITION, TO SAVE LIVES.

FOR EXAMPLE, IF YOU HAVE A CAR THAT IS GOING INTO ROAD -- ON THE ROAD IN ONE DIRECTION AND IT FOUND AN ACCIDENT OR SOME ROCKS THAT FALL FROM THE MOUNTAIN, HE IS GOING TO BE ABLE TO TELL THE CAR THAT IS CROSSING THAT CAR IN THE OPPOSITE DIRECTION, HEY, MOVE 50 CENTIMETERS ON THIS ROAD TO THE LEFT, BECAUSE, OTHERWISE, YOU WILL FIND A ROCK WHICH WILL BE REALLY DANGEROUS.

OKAY?

SO THIS IS A VERY INTERESTING EXAMPLE ABOUT WHY WE NEED MANY MORE ADDRESSES FOR ALL KIND OF DEVICES WHICH MORE AND MORE WILL BE BECOMING CONNECTED TO THE INTERNET.

THERE IS ONE MORE REASON FOR THIS NEED FOR MORE ADDRESSES, WHICH IS, WE HAVE BEEN CONNECTING MORE AND MORE USERS, AND ESPECIALLY WE HAVE BIG REGIONS LIKE LATIN AMERICA, CHINA, INDIA, AFRICA, WHICH HAVE NOT VERY WELL CONNECTED TO INTERNET SINCE A FEW YEARS AGO, AND NOW WHEN THEY BECOME GLOBALLY CONNECTED, OBVIOUSLY, THE NEED FOR -- DEMAND FOR ADDRESSES IS QUICKLY GROWING.

FINALLY, ONE MORE, IN THIS CASE, TECHNICAL AND ALSO INFORMATION (INAUDIBLE) DEVELOPMENT CONDITION MAKES THE NEED FOR ADDRESSES EVEN BIGGER.

IT'S ALL THESE TECHNOLOGIES THAT WE CALL "ALWAYS ON," WHICH MEANS WE HAVE NOT JUST MORE NETWORKS, BUT THOSE NETWORKS THAT BEFORE WERE TEMPORARILY CONNECTED TO THE INTERNET NOW BECOME PERMANENTLY CONNECTED, SO WE HAVE TECHNOLOGIES LIKE CABLE, DSL, POWERLINE, ETHERNET OR FIBER TO THE HOME, AND SO ON, WHICH MEANS MORE AND MORE HOMES AND OFFICES ARE BEING CONNECTED TO INTERNET, AND THE CONNECTION NEEDS TO BE PERMANENT.

AND THAT MEANS NOT JUST ONE ADDRESS, BUT MANY ADDRESSES FOR EVERY CONNECTED NETWORK.

SO THESE WERE THE MAIN REASONS FOR LOOKING INTO DEVELOPING A NEW PROTOCOL FOR INTERNET, THE SUCCESSOR FOR WHAT WE USE TODAY, WHICH IS IPV4.

THERE IS A VERY TYPICAL QUESTION, WHICH IS, IT'S NOT RIGHT; WE HAVE STILL MAYBE ABOUT, TODAY, PROBABLY 27, 28% OF THE IPV4 ADDRESSING SPACE STILL AVAILABLE.

YES, THAT'S TRUE.

BUT BECAUSE THE WAY WE HAVE BEEN USING THE ADDRESSES, THERE IS A LOT OF FRAGMENTATION, AND IT'S BECOMING MORE AND MORE DIFFICULT TO REALLY -- OR NOT TO SAY ALMOST IMPOSSIBLE -- TO REALLY MAKE USABLE 100% OF THE IPV4 ADDRESSING SPACE.

SO EVEN IF WE WANT TO USE ALL THE ADDRESSES, THAT'S SOMETHING THAT IS NOT GOING TO HAPPEN.

AND IF WE KEEP LOOKING AT THE WAY INTERNET IS GROWING, OBVIOUSLY, THAT MAKES REALLY DIFFICULT EVEN FOR MANY MORE YEARS TO KEEP USING JUST IPV4.

IT'S TRUE ALSO THAT WE HAVE INVENTED SOME MECHANISM, LIKE NAT, WHICH STANDS FOR NETWORK ADDRESS TRANSLATION, WHICH MEANS WE USE A SINGLE IPV4 ADDRESS FOR A PRIVATE NETWORK, FOR EXAMPLE, A COMPANY OR A HOME OR EVEN SOMETIMES, IN SOME COUNTRIES, THEY USE A SINGLE ADDRESS FOR MANY ISPS AND THEY USE DIFFERENT LEVELS OF NAT.

WE HAVE OTHER TECHNOLOGIES LIKE PPP, WHICH BASICALLY WAS USED AT OR WAS STARTED TO BE USED WHEN WE WERE USING MODEMS TO CONNECT DYNAMICALLY TO INTERNET.

SO ALL THIS TECHNOLOGY HAS ALLOWED UNTIL NOW TO KEEP CONTINUING THE GROWTH OF THE INTERNET.

BUT AT THE TIME BEING, WE ARE DEVELOPING ALREADY NEW APPLICATIONS WHICH MAKE REALLY, REALLY DIFFICULT CAN TO BE USED WITH IPV4, THE USAGE OF THINGS LIKE NAT, FOR EXAMPLE, INCREASE THE COST OF THE -- DEVELOPING THOSE APPLICATIONS.

AND IT'S REALLY BECOMING MORE AND MORE CHALLENGING TO DEVELOP NEW SOFTWARE AND NEW FACILITIES, NEW SERVICES, WHICH TAKE FULL ADVANTAGE OF THE INTERNET CAPABILITIES.

SO, BASICALLY, WE CAN SAY NAT HAS BEEN USEFUL UNTIL NOW, AND NAT GOES VERY WELL IN CLIENT SERVER ENVIRONMENTS.

BUT WHEN WE ARE TRYING TO CONNECT MORE APPLICATIONS LIKE COLLABORATIVE ENVIRONMENTS, PEER-TO-PEER GENERALLY, AND SO ON, IT'S REALLY NECESSARY TO ALLOW AN END-TO-END COMMUNICATION.

AND IF WE WANT ALSO TO DO END-TO-END SECURITY, AGAIN, THAT MEANS WE NEED PUBLIC ADDRESSES AT BOTH ENDS OF ANY COMMUNICATION.

AND THAT'S WHAT NAT IS MAKING NOW, LET'S SAY, THE NETWORK GROWS.

IT HAS BEEN HELPING UP TO A CERTAIN POINT, BUT IT REACHED THE POINT WHERE IT IS NOT ANYMORE HELPING AND IT'S MAKING ON THE OTHER WAY THE NETWORK MORE COMPLEX AND, IN GENERAL, THE DEVELOPMENT OF APPLICATIONS VERY, VERY EFFORTLY.

ONE MORE INTERESTING THING IS, AT THE SAME TIME, WE HAVE BEEN DEVELOPING IPV6, AND AS POINTED BEFORE, THE MAIN REASON WAS THE NEED FOR MORE ADDRESSES.

OBVIOUSLY, THAT MEANS WE NEED ADDRESSES WHICH ARE BIGGER IN TERMS OF HOW MANY BITS WE HAVE IN EVERY ADDRESS.

IN IPV4, WE HAVE 32 BITS.

IN IPV6, WE HAVE 128 BITS.

SO HAVING BIGGER ADDRESSES HAS ADDITIONAL BENEFITS.

SO, FOR EXAMPLE, HAVING THIS HIGHER NUMBER OF BITS MEANS WE CAN MAKE EASIER THE CONFIGURATION OF THE ADDRESSES.

IT MEANS, BASICALLY, WE HAVE A PROTOCOL THAT IT'S PLUG N' PLAY, WHICH CAN JUST CONNECT ANY DEVICE, NOT JUST A COMPUTER, BUT I AM TALKING ABOUT ANY SENSOR OR VERY, VERY SMALL GADGET THAT HAS NO KEYBOARD, NO CONFIGURATION SCREENS, NO WAY TO REALLY MAKE MANUALLY THE CONFIGURATION OF THAT DEVICE, BUT WHICH IPV6, WHEN THE DEVICE IS ATTACHED TO A NETWORK, IT WILL JUST WORK.

NOTHING ELSE NEEDS TO BE DONE.

SO THAT'S A VERY IMPORTANT FEATURE IF WE ARE MAKING INTERNET PERVASIVE ACROSS ALL KINDS OF ENVIRONMENTS.

ONE MORE IMPORTANT POINT ABOUT THIS BIGGER ADDRESS SPACE IS, WE MAKE ALSO EASIER THE MANAGEMENT AND THE DELEGATION OF THE ADDRESSES ITSELF, AND WE INCREASE THE LEVELS FOR THE ENERGY OF THE AGGREGATION OF THE NETWORK, OF THE DIFFERENT LEVELS FROM THE USERS TO THE SMALL ISPS, THE BIGGER ONES, THE CARRIERS, AND, IN GENERAL, INTERNET ITSELF.

AND AS I ALREADY MENTIONED, IF WE DON'T NEED NAT BECAUSE WE HAVE ENOUGH ADDRESSES FOR ANY NUMBER OF DEVICES IN ANY NUMBER OF NETWORKS, ALMOST UNLIMITED, IT MEANS WE CAN ALWAYS DO ANY END-TO-END CONNECTION.

AND THAT MEANS ANY OF THESE END-TO-END CONNECTIONS CAN ALSO USE END-TO-END SECURITY, WHICH IS ALWAYS NOT TRUE IN THE CASE OF IPV4.

IN ADDITION TO IMPROVE SOME FEATURES OF THE INTERNET PROTOCOL WITH THE BIGGER ADDRESSING SPACE, WE ALSO TOOK THE OPPORTUNITY TO DEVELOP NEW FEATURES OF THE PROTOCOL, LIKE, FOR EXAMPLE, WE MADE THE HEADER OF THE IPV6 PROTOCOL, WE WILL SEE IT IN A FEW SLIDES, LESS COMPLEX.

SO WE TOOK OUT SOME OF THE INFORMATION THAT WAS ACTUALLY NOT REALLY NEEDED TO SIMPLIFY THE NETWORKS, TRYING TO REALLY MAKE THE COMMUNICATION FROM END TO END MATCH SIMPLE.

WE TAKE ALSO THE CHANCE TO UPGRADE SOME FUNCTIONALITIES LIKE MULTICAST, WE HAVE SOMEHOW BETTER SUPPORT FOR MULTICAST WITH IPV6.

WE HAVE ALSO NEW FEATURES AND BETTER SUPPORT FOR MOBILITY, AND WE HAVE SOMEHOW BETTER SUPPORT FOR QUALITY OF SERVICE.

IS NOT TRUE IF YOU HEAR IPV6 MEANS QUALITY OF SERVICE, THAT'S NOT TRUE.

WHAT ACTUALLY MEANS IS WE HAVE IMPLEMENTED WAYS TO MAKE QUALITY OF SERVICE SUPPORT MUCH BETTER.

BUT, ACTUALLY, THE QUALITY OF SERVICE PROTOCOLS OFFERED BY IPV4 AND IPV6 ARE UP TO NOW THE SAME.

MAYBE IN THE FUTURE WE WILL TAKE THE OPPORTUNITY ALSO TO IMPROVE THAT.

BUT IT'S NOT THE CASE RIGHT NOW.

WE CANNOT SAY BECAUSE I AM RUNNING IPV6, I AM HAVING ALL THE TIME QUALITY OF SERVICE SUPPORT.

IT'S NOT THE CASE.

IT'S EXACTLY THE SAME WITH SECURITY, ACTUALLY.

MANY PEOPLE WILL BELIEVE THAT BECAUSE RUNNING IPV6, IT'S RUNNING MORE SECURE.

NO.

ACTUALLY, THE SECURITY PROTOCOL, WHICH IS IPSEC, INTERNET PROTOCOL SECURITY, IS THE SAME IN IPV4 AND IPV6.

WHAT IS TRUE IS THAT HAVING ENOUGH ADDRESSES FOR ANY DEVICE, WE CAN ALWAYS RUN A SECURE END-TO-END COMMUNICATION.

BUT AT THE END, IT DEPENDS ON THE NETWORK ADMINISTRATOR, ON THE APPLICATIONS, EVEN ON THE USER, IF HE WANTS TO TURN ON OR NOT THE SECURITY.

OKAY.

SO AS A KIND OF SUMMARY OF THESE FIRST SLIDES, WHICH ARE THE MAIN BENEFITS OF IPV6?

THE FIRST ONE IS, OBVIOUSLY, EXPANDED ADDRESSING CAPABILITIES.

SECOND ONE IS THE AUTOCONFIGURATION, WHAT WE CALL PLUG N' PLAY, AND ALSO RECONFIGURATION, BECAUSE IT'S THE SAME IF I MOVE FROM ONE NETWORK TO A NEW ONE, I GET THAT DEVICE AUTOMATICALLY RECONFIGURED.

WE SAY SERVERLESS AUTOCONFIGURATION, BECAUSE IN IPV4, WE HAVE THE DHCP PROTOCOL, WHICH DO SOMEHOW THIS FUNCTIONALITY.

BUT YOU NEED A DHCP SERVER.

IN IPV6, YOU DON'T NEED ANY SERVER TO DO THIS AUTOCONFIGURATION.

WE HAVE MORE EFFICIENT AND ROBUST MOBILITY MECHANISMS.

AND WE WILL HAVE SOME SLIDES LATER ALSO TO UNDERSTAND THE DIFFERENCE BETWEEN MOBILITY IN IPV4 AND IPV6 AND HOW MUCH BETTER IS IN THE CASE OF IPV6.

AND WE HAVE THE BUILT-IN, STRONG I.P. LAYER ENCRYPTION AND AUTHENTICATION, WHICH BASICALLY IN THIS CASE IS THE SAME AS IN IPV4.

AN INTERESTING DIFFERENCE ALSO HERE IS THAT AT THE BEGINNING, MANY IPV4 STACKS DIDN'T SUPPORT SECURITY, WHILE IN IPV6, ANY IPV6 STACK, TO BE COMPLIANT WITH THE IETF RECOMMENDATIONS, NEED TO SUPPORT SECURITY.

LAST ONE, THE STREAMLINED HEADER FORMAT AND THE FLOW IDENTIFICATION, WHICH IS THE POINT THAT WILL HELP IN THE FUTURE, IF NECESSARY, TO IMPROVE THE CLASSIFICATION OF FLOWS, OFFERING BETTER WAYS TO DO QUALITY OF SERVICE.

AND THERE IS ONE MORE THING THAT I WILL SAY IS PROBABLY FROM A VERY PERSONAL POINT OF VIEW ONE OF THE MOST IMPORTANT AND MANY TIMES WE DON'T REALLY TAKE CARE ABOUT THAT AT THE MOMENT IS WHAT I CALL EXTENSIBILITY.

IPV6 HAS BEEN DESIGNED IN SUCH A WAY THAT WE CAN, IN THE FUTURE, IMPROVE THE SUPPORT FOR NEW FEATURES, FOR NEW PROTOCOLS THAT WILL WORK TOGETHER WITH IPV6, WHICH IS NOT ALWAYS POSSIBLE, OR ALMOST IMPOSSIBLE MOST OF THE TIME, WITH IPV4.

SO THAT MEANS -- AND WE WILL SEE ALSO SOME SLIDES ABOUT THIS LATER -- IPV6 CAN BE EXTENDED ALMOST WITHOUT LIMITS IN A PRACTICAL POINT OF VIEW.

EVEN THIS EXTENSION CAN BE DONE WITHOUT THE NEED TO CREATE ALL THE NETWORKS AGAIN.

IT'S SOMETHING THAT WE WILL BE ABLE TO DO END-TO-END, WHICH MEANS WE KEEP SIMPLIFYING THE NETWORK, MAKING THE LIFE MUCH EASIER ALSO FOR ISPS, BECAUSE THEY WILL NOT DEPEND ON WHATEVER DEVELOPMENTS IN APPLICATIONS ARE DONE TO ACTUALLY KEEP UPGRADING THEIR NETWORK, AND, OF COURSE, INCREASING THEIR COST.

ONE TYPICAL QUESTION WHEN WE START TALKING ABOUT IPV6, I ALREADY MENTIONED IPV6 HAS 128 BITS INSTEAD OF 32 THAT HAS IPV4.

AND THE QUESTION, TYPICALLY, IS WHY 128 BITS HAVE BEEN SELECTED.

YES, THE IETF PROCESS, IETF AS PROBABLY YOU KNOW, IS INTERNET ENGINEERING TASK FORCE, IS THE BODY THAT TAKES CARE OF THE STANDARDIZATION OF ALL THE INTERNET AND RELATED PROTOCOLS.

SO WHEN IETF DECIDED WE NEED MORE ADDRESSES, AS WE SAID AT THE BEGINNING OF THIS PRESENTATION, LET'S LOOK FOR A NEW PROTOCOL, WHAT IETF DID IS AN OPEN CALL TO THE ENGINEERING COMMUNITY, AND THEN DIFFERENT ENGINEERS OR GROUPS OF ENGINEERS PROPOSED DIFFERENT WAYS TO DO THAT.

AND ONE OF THE THINGS THAT WE WERE TRYING TO LOOK IS HOW MANY HOSTS WE WANT TO BE ABLE TO HANDLE IN EVERY NETWORK, HOW MANY NETWORKS, AND SO ON.

SO ONE OF THE REQUIREMENTS WAS, WE NEED A SPECIFIC NUMBER OF BITS AS A MINIMUM.

AND AT THAT POINT, THERE WERE PROPOSED PROTOCOLS WHICH OFFERED 64 BITS AS A FIXED LENGTH.

SO IT'S SOMETHING THAT -- IT'S PRETTY FINITE AND YOU CANNOT GROW.

THERE WERE OTHER PROPOSALS STARTING AT 64 BITS, BUT ALLOWING GROWING UP TO 160 BITS.

AND THE DISADVANTAGE OF THIS, IT MAKES THE PROTOCOL MORE COMPLEX, BECAUSE YOU DON'T KNOW HOW MANY BITS THE ADDRESS OF THE NEXT PACKETS COMING WILL TAKE, SO IT'S A BIT COMPLEX ALSO FOR ROUTERS.

AND THEN WE COME OUT TO A COMPROMISED SOLUTION, WHICH WAS, WE REALLY BELIEVE 128 BITS, IT'S MORE THAN ENOUGH.

AND THAT SHOULD BE OKAY.

AND IF WE HAVE FIXED LENGTH ADDRESSES, IT MEANS THEY ARE SIMPLE TO PROCESS.

SO THAT'S WHAT WE HAVE.

WE HAVE 128 BITS, FIXED LENGTH.

AND, BASICALLY, THE NUMBER THAT YOU SEE IN THE LAST ROW IN THE SCREEN IS THE TOTAL NUMBER OF POSSIBLE ADDRESSES WITH 128 BITS, WHICH IS THE FINAL DECISION OF IETF.

ANOTHER FREQUENT QUESTION IS, WHAT HAPPENED TO IPV5, BECAUSE IF WE ARE USING IPV4 AND THE NEXT VERSION IS IPV6, WELL, BASICALLY, THERE WAS ALMOST AT THE SAME TIME A NEW STREAMING PROTOCOL, WELL, IT WAS ACTUALLY THE FIRST SYSTEM IN PROTOCOL DESIGN, WHICH TAKES -- WHICH TOOK NUMBER 5 FOR BEING LABELED; RIGHT?

SO IN ORDER TO AVOID ANY CHANCE FOR CONFLICT BETWEEN HARDWARE THAT MAY HAVE IMPLEMENTED ALREADY THIS STREAMING PROTOCOL, WE DECIDED TO USE 6.

AND AS YOU CAN SEE ALSO IN THE SLIDE, THERE WERE OTHER NUMBERS BEING USED FOR DIFFERENT PROPOSALS, AS I JUST MENTIONED, THAT WERE CANDIDATES TO BE THE IPNG, THE I.P. NEXT GENERATION PROTOCOL, WHICH WAS RENAMED JUST THREE OR FOUR YEARS AGO TO IPV6.

SO WE HAD IPV6 BASICALLY COMING FROM WHAT WE NAMED AT THAT TIME SIMPLE IP-PLUS.

THEN WE HAVE OTHER PROPOSALS COMING FROM DIFFERENT AUTHORS, WHICH WERE CALLED IPV7, TPIX.

AND THEY ACTUALLY JOINED IN SOMETHING THAT WE CALL IT CATNIP.

AND THEN WE HAVE PIP, TUBA, AND SO ON.

SO DIFFERENT CANDIDATE PROTOCOLS.

AND THE FINAL DECISION WAS MAINLY, LET'S TAKE SIMPLE IP-PLUS, CP, AND THAT'S WHAT WE CALL TODAY, BASICALLY, IPV6, WITH MANY IMPROVEMENTS THAT WE TOOK ALSO SOME EXPERIENCE ABOUT THE DESIGN OF THE OTHER PROTOCOLS THAT WERE CANDIDATE TO REPLACE IPV4.

OKAY.

LET'S GO A LITTLE BIT, NOT TOO MUCH MORE, BUT JUST TO HAVE AN IDEA ABOUT A QUICK COMPARISON BETWEEN IPV4 AND IPV6, SO A LITTLE BIT MORE TECHNICAL.

LET'S TRY TO LOOK AT THE DIFFERENCE BETWEEN THE IPV4 HEADER AND THE IPV6 ONE.

IN CASE YOU ARE INTERESTED IN LOOKING WITH MUCH MORE DETAIL AT THIS, THE MAIN DOCUMENT YOU SHOULD LOOK FOR IS RFC2460 WHICH IS THE MAIN DESCRIPTION OR THE MAIN DOCUMENT FROM IETF DESCRIBING THE IPV6 PROTOCOL BASIC.

SO WE HAVE ON THE SCREEN RIGHT NOW THE FORMAT OF THE IPV4 HEADER.

THE IPV4 HEADER HAS 20 BYTES PLUS OPTIONS. THE OPTIONS CAN TAKE UP TO 40 BYTES. IT MEANS THE IPV4 HEADER CAN GROW OR CAN HAVE -- IT HAS A VARIABLE LINE SIZE AND IT CAN BE FROM 20 TO 60 BYTES. OKAY?

IN THE SLIDE, YOU CAN SEE SOME OF THE FIELDS IN YELLOW COLOR. THOSE ARE THE FIELDS THAT ARE BEING MODIFIED IN IPV6 WHILE SOME OTHERS IN RED IN THE SCREEN ARE THOSE FIELDS THAT WILL BE DISSIPATING IN THE IPV6 HEADER.

SO THIS IS THE IPV6 HEADER FORMAT.

AS I ALREADY MENTIONED BEFORE, WE HAVE TRIED TO SIMPLIFY AS MUCH AS POSSIBLE THIS HEADER. SO WE MOVE FROM 12 FIELDS IN IPV4 TO ONLY EIGHT FIELDS IN IPV6. OBVIOUSLY WE HAVE INSTEAD OF 32 BITS, SOURCE AND DESTINATION ADDRESS, NOW WE HAVE 128 BITS, SOURCE AND DESTINATION.

SO THAT MEANS EVEN WE HAVE LESS FIELDS, THE TOTAL SIZE OF THE HEADER IS BIGGER. AND WE HAVE ACTUALLY SOMETHING IN THE MIDDLE BETWEEN WHAT IT CAN BE THE MINIMUM LENGTH OR THE SHORTER IPV4 HEADER, WHICH WAS 20 BYTES, UP TO THE MAXIMUM, WHICH WAS 60. SO WE HAVE SOMETHING IN THE MIDDLE, WHICH BECOMES 40 BYTES.

MORE INTERESTING THINGS ON THIS HEADER IS WHILE ON THE SCREEN YOU SEE BASICALLY TWO ROWS IN GREEN COLOR. THIS MEANS IN TOTAL, 64 BITS. AND THEN WE HAVE 228 BITS ADDRESSES, WHICH ARE THE SOURCE AND DESTINATION. AND IN FACT, EVERY IPV6 ADDRESS CAN BE CONSIDERED AS TWO PARTS OF 64 BITS, EACH ONE.

SO SOMEHOW, WE CAN SEE THAT ALL THE FIELDS ARE ALIGNED AT 64 BITS BOUNDARIES. AND THE MEANING FOR THAT IS ALSO TO SOMEHOW MAKE SIMPLE THE DESIGN OF SOFTWARE AND HARDWARE PROCESSING IPV6 PACKETS.

BECAUSE AT THE TIME OF THE DESIGN OF IPV6, WE ALREADY KNEW THAT THE CPUS THAT WERE BEING DESIGNED AT THAT TIME, THE MICROCONTROLLERS, THE MICROPROCESSORS, WERE ALREADY HAVING 64 BITS REGISTERS.

SO WE WANTED TO MAKE SURE THAT THEY WILL ALIGN CORRECTLY IN THOSE REGISTERS, ALL THE INFORMATION NEEDED IN THE IPV6 HEADER.

SOME OF THE THINGS THAT ARE INTERESTING ALSO TO REMARK IS WE AVOID DOING SOMETHING THAT IT WAS DONE IN EVERY IPV4 PACKET, WHICH WAS A CHECKSUM VERIFICATION OF BITS THAT MAY BE LOST OR CHANGED OR WHATEVER. AND WE AVOIDED THAT MAINLY BECAUSE OTHER PROTOCOLS LIKE ATM, PPP WHICH ARE TYPICALLY USED TO TRANSPORT IP INFORMATION ARE READY TO DO THAT CHECKSUM. SO DOING IT TWICE, IT MEANS A WASTE OF BITS AND ALSO RESOURCES.

ANOTHER INTERESTING CHANGE IS WE HAD THREE FIELDS IN IPV4 WHICH WERE MEANT TO ALLOW DOING FRAGMENTATION IN THE PART FROM SOURCE TO DESTINATION. SO IF ANY OF THE LINKS -- FOR EXAMPLE, HAS VERY LOW CAPACITY AND YOU REALLY NEED TO SEND VERY, VERY SMALL PACKETS, THEN THE ROUTERS IN THE WAY WILL BE ABLE TO DETECT THAT AND WILL BREAK THE PACKETS INTO SMALLER ONES.

IN IPV6, WE DO THAT END-TO-END.

SO AGAIN, WE ARE SOMEHOW SIMPLIFYING THE DESIGN OF THE NETWORK AND THE ROUTERS, MAKING LESS FUNCTIONALITIES NEEDED ACROSS THE PATH. TRYING TO PUT SOME MORE INTELLIGENCE, WHICH IS TO LABEL AT THE END STATIONS. THAT DOESN'T MEAN WE NEED MUCH MORE POWER TO USE IPV6, BECAUSE IN FACT, TODAY, MOST OF THE COMPUTERS ALREADY HAVE THIS POWER, OR EVEN MUCH MORE EXTRA POWER THAN NEEDED. AND MORE AND MORE, EVEN ALL THE INTERFACES LIKE ETHERNET OR WIRELESS AND SO ON HAVE THEIR OWN PROCESSORS TO TAKE CARE OF THE IP PROTOCOL THING.

SO IT MEANS WE ARE NOT REALLY SAYING WE SIMPLIFIED THE NETWORK AT THE COST OF INCREASING THE COMPLEXITY AND CONSEQUENTLY THE COST OF THE HOST. NOT REALLY, WE ARE JUST TAKING ADVANTAGE OF WHAT IS ALREADY THERE.

SO WE JUST WANT TO MAKE A SHORT SUMMARY OF THE CHANGES FROM THE IPV4 TO THE IPV6 HEADER.

WE HAVE THE LENGTH OF THE HEADER NOW IS FIXED AND IT'S 40 BYTES. WE HAVE INCREASED THE NUMBER OF BITS FOR THE ADDRESSES FROM 32 TO 128 BITS. WE HAVE FRAGMENTATION AND OPTION FIELDS THAT ARE NOT PART ANYMORE OF THE BASE HEADER IN IPV6.

WE HAVE REMOVED THE CHECKSUM.

WE HAVE SOME FIELDS THAT HAVE A NEW NAME, BUT THE SAME FUNCTIONALITY, LIKE, FOR EXAMPLE, TYPE OF SERVICE IN IPV4 NOW BECOMES TRAFFIC CLASS IN IPV6.

THE INFORMATION ACTUALLY IS THE SAME BUT WE JUST TOOK THE OPPORTUNITY TO USE A BETTER NAME.

AND, FOR EXAMPLE, WE HAVE ANOTHER ONE, WHICH IS A SIMILAR SITUATION, WHICH IS TIME TO LIFE, WHICH ACTUALLY WAS NOT MEASURING TIME ELAPSED IN THE NETWORK BUT THE NUMBER OF HOPS SO WE CALL IT HOP LIMIT. AND I ALREADY MENTIONED ABOUT THE ALIGNMENT OF THE BITS IN THE FIELDS TO 64 BITS.

OKAY.

I MENTION ALSO ABOUT THE EXTENSION HEADERS.

LET'S TAKE TWO EXAMPLES. THE ONE IN THE TOP IS WHAT WILL BE THE MINIMUM PACKET TRANSMITTED TO INTERNET FOR ANY KIND OF DATA TRANSMISSION WHERE WE WILL HAVE THE IPV6 HEADER, AND THEN THIS HEADER POINTS TO THE NEXT TYPE OF HEADER WHICH IS THE TCP HEADER AND THE TCP HEADER CONTAINS THE ACTUAL PAYLOAD, THE DATA. OKAY IN.

IF WE GO TO THE LAST EXAMPLE, WE HAVE THE IPV6 HEADER IN THIS CASE POINTING TO A SECURITY HEADER, BECAUSE I WANT TO USE IPSEC IN THIS COMMUNICATION. AND THEN LET'S SAY I HAVE A VERY SMALL LINK, WHICH IS PERFORMING VERY BAD AND I NEED TO DO SOME FRAGMENTATION. SO THEN THE SECURITY HEADER CAN POINT TO A FRAGMENTATION HEADER. AND THEN THE FRAGMENTATION HEADER WILL POINT TO THE TCP, WHICH CONTAIN THE DATA.

SO AS YOU CAN SEE THIS KIND OF CHAIN BETWEEN DIFFERENT HEADERS MEANS WE CAN ACTUALLY EXTEND THE PROTOCOL AS MUCH AS NEEDED.

AND THE MOST IMPORTANT THING IS THAT MOST OF THE TIME, ALL THESE NEW HEADERS ARE NOT BEING PROCESSED BY THE NETWORK; ARE ONLY CONSIDERED AT THE END STATIONS, FROM SOURCE TO DESTINATION.

SO THAT MEANS THAT IF WE ARE USING A NEW APPLICATION AND BY THE WAY THIS IMPLICATION REQUIRES TO IMPLEMENT A NEW PROTOCOL, WE DO NOT NEED TO SAY TO THE ISPS LET'S GO AND UPGRADE THE NETWORK TO SUPPORT THIS PROTOCOL. JUST WHEN YOU UPGRADE YOUR OPERATING SYSTEM, WHICH PROBABLY WILL BE DONE AUTOMATICALLY WHEN YOU INSTALL THIS NEW APPLICATION, AND IT'S SOMETHING THAT YOU ONLY NEED TO COULD FOR THOSE HOSTS THAT ARE ACTUALLY GOING TO USE THIS NEW APPLICATION THAT REQUIRES THIS NEW PROTOCOL. OKAY?

SO IT'S A VERY IMPORTANT CHANGE FROM WHAT WE HAVE TODAY, THAT MOST OF THE TIME ANY PROTOCOL CHANGE WILL REQUIRE TO UPGRADE THE NETWORK. AND THAT'S THE REASON IT'S ACTUALLY NOT DONE. AND THAT'S THE REASON, ALSO, WHY ADDING NEW FUNCTIONALITIES INTO THE NETWORK, IT'S TYPICALLY NOT DONE AND WE NEED TO GO THROUGH KINDS OF TUNNELS AND OTHER ALTERNATIVES TO SUPPORT NEW FUNCTIONALITIES.

OBVIOUSLY, AGAIN, AND IT'S VERY IMPORTANT TO INSIST ON THAT, WE ARE TRYING TO SIMPLIFY AS MUCH AS POSSIBLE THE NETWORK AND GET THE NETWORK AS MUCH POWERFUL IN THE SENSE THAT THE RESOURCES AVAILABLE IN THE NETWORK ARE GOING TO BE USED JUST FOR WHAT THE NETWORK IS MEANT TO, WHICH IS JUST FORWARDING DATA. SENDING DATA FROM ONE POINT TO ANOTHER ONE.

SO WE TRY TO KEEP DOING THAT AT HIGHER PERFORMANCE AND MAKE POSSIBLE NEW FUNCTIONALITIES BEING IMPLEMENTED ONLY END-TO-END.

OKAY. I MENTIONED MOST OF THE TIME, BECAUSE THERE ARE SITUATIONS, AND ACTUALLY THERE IS ONE TYPE OF EXTENSION HEADER WHICH IS HOP-BY-HOP EXTENSION HEADER, WHICH IT'S REALLY BEING PROCESSED BY ROUTERS.

BUT IN GENERAL, THE VENDORS WILL NOT LIKE TO IMPLEMENT THIS TYPE OF FUNCTIONALITY BECAUSE IT MEANS SOMEHOW MAKING THE HARDWARE MORE COMPLEX AND MEANS TYPICALLY DOING PART OF THE FUNCTIONALITIES OF THE HARDWARE PROCESSED IN SOFTWARE INSTEAD OF BY DEDICATED CHIPS DESIGNED FOR THAT PURPOSE.

SO MOST OF THE TIME WE ARE NOT GOING TO SEE NEW HEADERS THAT REALLY NEED TO UPGRADE THE NETWORK.

NOW, ANOTHER SMALL COMPARISON BETWEEN IPV4 AND IPV6 IN THIS CASE LOOKING AT THE CONTROL PLANE, WE HAVE ON YOUR RIGHT THE IPV4 BUILDING BLOCKS. SO WE HAVE AN ETHERNET OR WIRELESS INTERFACE. WE HAVE ACTUALLY FIVE BUILDING BLOCKS. ONE IS THE ETHERNET ITSELF, THEN WE HAVE THE ARP PROTOCOL, THE IPV4 ITSELF, ICMP, AND IGM TO SUPPORT MULTICAST.

IN IPV4 WE HAVE SUPPORT FOR BOTH MULTICAST AND BROADCAST.

IF WE LOOK NOW AT THE OTHER SIDE OF THE SLIDE, WHEN WE HAVE IPV6, WE HAVE BASICALLY ONLY THREE BUILDING BLOCKS. WE HAVE ETHERNET EXACTLY THE SAME AS IN IPV4, IPV6, AND THEN ICMPV6.

ICMPV6 IS REPLACING THE FUNCTIONALITIES OF BOTH THE MULTICAST AND ALSO THE FUNCTIONALITIES REQUIRED FOR ARP.

SO EVEN IF WE HAVE PICTURED HERE (INAUDIBLE) DISCOVERY AND MULTI-LISTENER DISCOVERY AS PART OF ICMPV6, THEY ARE NOT ISOLATED BLOCKS. THEY ARE ALL PART OF ICMPV6.

OKAY. SO AS WE CAN SEE, MUCH MORE SIMPLE AND WE DON'T HAVE SUPPORT FOR BROADCAST IN IPV6.

WE DON'T HAVE SUPPORT FOR BROADCAST IN IPV6, BUT WE CAN ALWAYS DO FUNCTIONALITIES EQUIVALENT TO BROADCAST DOING A MULTICAST TO ALL THE NETWORK. BUT MOST OF THE TIME WE DON'T REALLY NEED THAT SO WE AVOID DOING THIS KIND OF BROADCAST PACKET THROUGHOUT THE NETWORK IN IPV6.

SOME MORE SMALL CHANGES IN IPV6, NOW LOOKING TO ADDRESSING AND ROUTING.

IN IPV4, WE REPRESENT ADDRESSES AS DECIMALS, AND A TYPICAL IPV4 ADDRESS COULD BE 13.1.69 -- SORRY, .68.3. BUT IF WE TRIED TO REPRESENT 128 BITS THE SAME WAY, IT WILL BECOME TOO LONG. SO WE DECIDED TO USE EXTRA DECIMAL FOR THE TEXT REPRESENTATION OF THE IPV6 ADDRESSES.

SO WE USE IN THIS CASE A COLON TO SEPARATE EVERY 16 BITS, AND EVEN MANY TIMES WE WILL BE ABLE TO REPLACE SETS OF CONSECUTIVE ZEROS WITH SOMETHING LIKE, IN THIS CASE, COLON COLON.

SO WE HAVE THE ADDRESS FF01:0:0, SO ON, THEN COLON 43, WE WILL BE ABLE TO SAY FF01::43.

SO WE REALLY MAKE IT MUCH SIMPLER.

OBVIOUSLY, AS WE DON'T SAY HOW MANY ZEROS ARE WE COMPRESSING, IT MEANS WE CAN ONLY MAKE A SINGLE COMPRESSION IN EVERY ADDRESS. SO TYPICALLY WE WILL TAKE THE BIGGER CHUNG OF CONSECUTIVE ZEROS TO GET THAT COMPRESSED INTO COLON COLON.

WE HAVE ALSO AN OPPORTUNITY TO REPRESENT WHAT WE CALL IPV4 COMPATIBLE ADDRESSES, AND THEN WE SAY 96 BITS OF ZERO, WHICH MEANS COLON COLON AND THEN THE IPV4 ADDRESS.

SO IT WILL BE ::13.1.68.3.

AND THEN FINALLY, AS WE USE COLON IN THE URLS TO SEPARATE THE PORT NUMBER, WE NEED A WAY TO DISTINGUISH THE COLON BEING USED FOR THE PORT NUMBER FROM THE COLON TO SEPARATE THE DIFFERENT BLOCKS OF 16 BITS IN THE IPV6 ADDRESSES. SO WE USE A NOTATION WHICH MEANS BASICALLY ENCLOSING THE IPV6 ADDRESS IN SQUARE BRACKETS. SO WE WILL USE SQUARE BRACKETS, AND IF WE NEED TO WRITE A PORT NUMBER -- FOR EXAMPLE, 8080 -- WE WILL SAY FF01::43, CLOSING IS SQUARE BRACKET, COLON 80. OR 8080 OR WHATEVER. RIGHT?

ADDRESS TYPES, IN IPV6 BASICALLY WE HAVE MORE OR LESS THE SAME BLOCKS OF ADDRESS TYPES. WE HAVE UNICAST WHEN WE ARE USING A COMMUNICATION ONE-TO-ONE. MULTICAST, ONE-TO-MANY. ANYCAST, ONE TO THE NEAREST. ANYCAST IS NOT TOO MANY PEOPLE KNOW ABOUT ANYCAST, BUT ICANN MENTIONED A VERY, VERY SIMPLE EXAMPLE WHICH IS THE ROOT SERVERS. YOU KNOW THAT BY DESIGN OF THE DNS SERVERS OR THE DNS PROTOCOL, ACTUALLY, THERE IS A MAXIMUM NUMBER OF SERVERS WHICH IS 13. BUT IN THE LAST YEARS WE HAVE BEEN ABLE TO SOMEHOW MIRROR OR CLONE THOSE SERVERS AND THE PROTOCOL THAT WE USED TO DO THAT, IT'S ACTUALLY USING ANYCAST ADDRESSES.

SO BASICALLY WHAT WE DO IS WE HAVE THE SAME CONTENTS IN DIFFERENT SERVERS LOCATED IN DIFFERENT NETWORKS. MAYBE IN DIFFERENT PARTS OF THE WORLD. WE CAN REPLICATE THAT AS MUCH AS WE WANT. AND WE USE THE SAME ADDRESS FOR ALL THOSE SERVERS.

BUT YOU ARE ONLY REACHING THE SERVER BY THE INFORMATION, THE ROUTING INFORMATION THAT IS BEING ANNOUNCED BY THE ISPS THAT THESE NEAREST TO YOUR ATTACHMENT POINT IT TO THE NETWORK. SO THAT IS BASICALLY ANYCAST. YOUR LOOKING FOR THE NEAREST ONE.

NOW, WELL, WE HAVE ALSO SPACE FOR -- WHICH IS RESERVED FOR FUTURE NEEDS FOR MORE ADDRESSING TYPES, SO THAT'S SOMETHING THAT, IF NEEDED, WILL COME. AND THEN LOOKING INTO THE UNICAST ADDRESSES WHICH ARE THE ONES TYPICALLY WE USE MOST OF THE TIME, WE HAVE THE EQUIVALENT TO THE PUBLIC ADDRESSES IN IPV4. IN IPV6 THEY ARE CALLED GLOBAL ADDRESSES. AND THEN WE HAVE LINK-LOCAL ADDRESSES AND AS THE NAME SAYS, THOSE LINK-LOCAL ADDRESSES ARE ONLY VISIBLE OR REACHABLE INSIDE OF THE LOCAL-AREA NETWORK, SUBNET. SO WHERE YOU ARE CONNECTED TO, BASICALLY.

WE HAVE DEFINED ALSO IN IETF WHAT WE CALL THE SITE LOCAL, BUT WE DECIDED FOR DIFFERENT REASONS THAT THEY ARE NOT LONGER SO USEFUL AS WE CONSIDERED INITIALLY SO WE DECIDED TO DEPRECATE THAT TYPE OF ADDRESSES AND INSTEAD WE DESIGNED A NEW ONE WHICH IS UNIQUE LOCAL WHICH SOMEHOW MAKE AN ALTERNATIVE TO PRIVATE SPACE IN IPV4, BUT WHICH THE POSSIBILITY OF AVOIDING COLLISIONS BETWEEN DIFFERENT PRIVATE NETWORKS; OKAY?

SO THE CHANCE TO HAVE A COLLISION IS ALMOST IMPOSSIBLE.

WE HAVE THE IPV4 COMPATIBLE ADDRESSES THAT I HAVE ALSO ALREADY IN THE PREVIOUS SLIDE.

IF YOU WANT TO IDENTIFY WHEN YOU SEE AN IPV6 ADDRESS WHICH KIND OF ADDRESS IS THAT ONE, YOU SHOULD LOOK AT THE BINARY OF THE FIRST DIGITS AND THEN YOU WILL SEE THAT ZERO ZERO ONE, FOR EXAMPLE, IS THE GLOBAL UNICAST ADDRESSES WHICH ARE THE MORE COMMON ONES, OR MULTICAST IS STARTING WITH EIGHT CONSECUTIVE 1S, AND SO ON. THESE ADDRESSES THAT WE ARE USING RIGHT NOW IS ONLY ONE-EIGHTH OF THE TOTAL AVAILABLE IPV6 ADDRESSING SPACE. SO WE HAVE STILL SEVEN-EIGHTHS TO BE DEFINED IN THE FUTURE IF NEEDED OR TO BE ALLOCATED TO GLOBAL UNICAST AND SO ON.

I MENTIONED BEFORE WHEN WE SEE AN IPV6 ADDRESS, EVEN IF IT'S 128 BITS, ACTUALLY WE CAN REPRESENT THAT AS TWO BLOCKS OF 64 BITS, EACH ONE. BASICALLY, WE HAVE THE LOW ORDER 64 BITS WHICH IS WHAT WE CALL THE INTERFACE ID, AND THEN THE REST ADDITIONAL 64, IN THIS CASE THE HIGH ORDER 64 BITS, WHICH BASICALLY SAY WHICH TYPE OF ADDRESS WE HAVE. IN THIS CASE, IT STARTS WITH ZERO ZERO ONE, IT MEANS GLOBAL UNICAST. AND THEN WE HAVE WHAT WE CALL THE GLOBAL ROUTING PREFIX WHICH IS 45 BITS, AND THE SUBNETWORK ID WHICH IS 16 BITS.

THAT TYPICALLY MEANS ALLOCATING OR ASSIGNING 48 BITS TO EVERY END SITE, AND THAT MEANS EVERY END SITE WILL BE ABLE TO SUBNET THAT SPACE INTO 65,000 SUBNETWORKS ACCORDING TO THIS STRUCTURE. SO THIS IS HOW WE CAN MAKE THE AGGREGATION OF THE ADDRESSES AND HOW THE ROUTING SPACE IS SEPARATED FROM THE INFORMATION WE HAVE IN EVERY SITE AND THEN IN EVERY SUBNETWORK.

TODAY IN PRODUCTION NETWORKS, TYPICALLY THE PREFIX YOU WILL SEE WILL BE STARTING WITH SOMETHING LIKE, IN HEXADECIMAL, 2001, 2003, 2400, 2800 AND SO ON. SO THAT'S THE PREFIX THAT YOU ARE GOING TO SEE AT LEAST AT THE BEGINNING MORE FREQUENTLY.

REGARDING THE INTERFACE ID WHICH IS AGAIN THE 64 LOW-ORDER BITS OF AN IPV6 ADDRESS, THE WAY THIS INTERFACE ID IS CREATED, IT -- THERE ARE SEVERAL WAYS, BASICALLY.

BY DEFAULT, WHAT WE ARE USING IS STARTING FROM THE 48 BITS MAC ADDRESS, FOR EXAMPLE, OF A WIRELESS OR ETHERNET INTERFACE, WE BUILT UP THE 64 BITS EUI-64 IDENTIFIER, AND THAT MEANS ACTUALLY YOU WILL BE ABLE TO IDENTIFY A MAC ADDRESS IN THE LOW ORDER 64 BITS.

THAT'S THE REASON ALSO WE WORK IT FOR PRIVACY REASONS IN WHAT WE CALL PRIVACY EXTENSIONS WHICH BASICALLY MEANS WHEN YOU ARE USING CLIENT-TO-SERVER COMMUNICATION, YOU DON'T REALLY NEED TO BE IDENTIFIED BECAUSE YOU ARE, FOR EXAMPLE A WEB SERVER REQUESTING TO THE WEB SERVER THE INFORMATION AND YOU ARE ALREADY TELLING THE WEB SERVER WHERE THIS INFORMATION SHOULD BE SENT SO THAT MEANS THIS PRIVACY ADDRESS CAN RANDOMLY CHANGE WITH THE TIMES.

SO, FOR EXAMPLE, TO AVOID BEING TRACKED WHEN YOU ARE BROWSING ANY GIVEN CONTENTS OR WHATEVER. BUT TYPICALLY THIS IS ONLY USED IN CLIENT-TO-SERVER APPLICATIONS BECAUSE IF WE REALLY WANT TO GO FOR A PEER-TO-PEER OR CLIENT-TO-CLIENT COMMUNICATION, WE REALLY NEED TO HAVE STABLE ADDRESSES. AND THAT'S, FOR EXAMPLE THE CASE IF WE ARE GOING TO HAVE A VOICE OVER IP COMMUNICATION. WE REALLY WANT TO BE REACHABLE SO OTHERS CAN CALL IN. OTHERWISE WE WILL BE IN A SIMILAR SITUATION AS WHAT WE HAVE TODAY WHICH NAT; RIGHT?

STILL, THERE ARE OTHER WAYS TO CREATE THIS INTERFACE ID. ONE OF THEM IS SPECIAL ENTERPRISES. THEY WANT TO ASSIGN CONCRETE ADDRESSES TO THE HOST. SO, FOR EXAMPLE, THEY CAN STILL USE DHCPV6, IT'S JUST AN EXTENSION TO THE SEP TO SUPPORT IPV6 ADDRESSES. ACTUALLY, IT'S A MUCH MORE COMPLEX PROTOCOL, BUT FROM A USER'S PERSPECTIVE, IT'S BASICALLY ONE MORE VERSION OF DHCP, AND WE CAN STILL MANUALLY CONFIGURE THE ADDRESSES AS WE DO IN IPV4. AND MAYBE IN THE FUTURE WE CAN FIND OTHER WAYS TO DO THAT ALSO.

SOME ADDRESSES THAT MAY BE INTERESTING TO REMEMBER, I WOULD SAY THE MOST IMPORTANT ONE, MOST OF YOU KNOW IN IPV4 WE HAVE THE LOOP-BACK ADDRESS WHICH IS ONE TO SEVEN, .0.0.1. IN IPV6 THAT'S ::1. SO IT MEANS ONE 27 -- 127 BITS OF ZERO, AND THEN THE LAST ONE SET TO ONE.

WHAT ABOUT ROUTING, AND WE ARE JUST SIX SLIDES FROM THE END OF THE PRESENTATION.

BASICALLY, WE ARE USING BOTH UNICAST AND MULTICAST, THE SAME ROUTING PROTOCOLS AS WE USE TODAY IN IPV4. BASICALLY THOSE PROTOCOLS HAVE BEEN UPGRADED TO SUPPORT BOTH IPV4 AND IPV6, AND THEY ARE WIDELY IMPLEMENTED ACROSS MOST OF THE ROUTING PLATFORMS THAT ARE ALREADY IMPLEMENTED IN THE NETWORKS EVERYWHERE.

SO IT'S NOT A BIG CHANGE. JUST ONE MORE UPGRADE OF THESE ROUTING PROTOCOLS.

A COUPLE OF SLIDES ABOUT MOBILITY. IT'S IMPORTANT TO CLARIFY WHEN WE ARE TALKING ABOUT IP MOBILITY WHAT WE MEANT.

BASICALLY IP MOBILITY IS TYPICALLY ASSOCIATED WITH WIRELESS INTERFACES, BUT IT'S NOT THE ONLY SITUATION. ACTUALLY, I COULD BE USING MY LAPTOP TO DO, LET'S SAY, A VOICE OVER IP CALL AND BE HERE CONNECTED WITH ETHERNET AND THEN GOING TO GO OUT OF THE ROOM AND THEN DISCONNECT MY ETHERNET, TURN ON MY WIRELESS, AND KEEP GOING THE SAME VOICE OVER IP COMMUNING THROUGH THE WIRELESS. SO EVEN IF WE ARE NOT JUST TALKING ABOUT WIRELESS TECHNOLOGIES, THAT COULD ALSO MEAN IP MOBILITY. BUT IT'S TRUE THAT IN GENERAL, IP MOBILITY IS MORE VISIBLE AND MORE USEFUL WHEN WE ARE USING THE SAME OR DIFFERENT KINDS OF WIRELESS TECHNOLOGIES. LIKE, FOR EXAMPLE, A VOICE OVER IP PHONE USING WIRELESS INTERFACE BUT ALSO SUPPORTING GPRS OR UMTS AND MOVING FROM ONE NETWORK TO ANOTHER WHEN GOING OUT, FOR EXAMPLE, FROM THE UNDERGROUND TO THE OTHER SIDE OF THE STREET. AND THEN THE COVERAGE FOR ONE TYPE OR OTHER OF NETWORK WOULD CHANGE. BUT I WANT TO KEEP GOING, MY CALL, AND NOT NEED TO RESTART IT.

SO THAT'S THE BASIC CONCEPT OF MOBILITY. AND WHAT I WANT TO SHOW YOU, BECAUSE I THINK IT'S A VERY, VERY DESCRIPTIVE AND GOOD EXAMPLE OF THE DIFFERENCE BETWEEN TRYING TO DO MOBILITY WITH IPV4 OR DOING MOBILITY WITH IPV6, HOW MUCH POWERFUL IS IPV6 IN THAT SENSE.

SO IN THIS EXAMPLE, WE HAVE, LET'S SAY, MY LAPTOP. NORMALLY IT SHOULD BE CONNECTED TO MY NETWORK, TO MY HOME NETWORK IN MADRID. AND TO SUPPORT MOBILITY, I NEED TO HAVE IN MY HOME NETWORK WHAT WE CALL THE HOME AGENT; OKAY?

AND THEN I AM NOW HERE CONNECTED IN SAO PAULO, AND TO SUPPORT MOBILITY, I NEED TO HAVE ANOTHER BOX OR FUNCTIONALITY IN A ROUTER OR A SERVER WHICH WE CALL THE FORWARDING AGENT. AND THEN THERE IS A HOST ON (INAUDIBLE) INTERNET THAT WANT TO, FOR EXAMPLE, START A VOICE OVER IP CALL TO ME. SO THIS HOST WILL LOOK FOR MY ADDRESS, OBVIOUSLY BY DNS TYPICALLY WILL GET MY HOME ADDRESS WHICH IS IN MADRID, AND THEN THE HOME AGENT WILL FORWARD THAT PACKET TO THE FOREIGN AGENT HERE IN THE SAO PAULO NETWORK.

I WILL GET, THEN, THE PACKET, AND I WILL BE ABLE MAYBE, DEPENDING ON THE NETWORK CONFIGURATION, DEPENDING ON FIREWALLS AND NATS AND SO ON, MAYBE I WILL BE ABLE TO REPLY BACK TO THE CORRESPONDING HOST, BUT MAYBE THIS COMMUNICATION WILL NOT BE POSSIBLE, AND I WILL NEED TO GO BACK ALL THE WAY THROUGH.

OKAY?

AND ANY COMMUNICATION WILL NEED TO BE DONE USING THIS PATH, WHAT WE CALL THE TRIANGULAR ROUTING, OKAY?

SO WE HAVE DIFFERENT HOPS ACROSS THE COMMUNICATION.

IT MEANS EXTRA LATENCY AND IT MEANS MORE BANDWIDTH USED IN DIFFERENT NETWORKS.

HOWEVER, IN IPV6, THERE IS A VERY, VERY SMALL CHANGE.

AND THE CHANGE, BASICALLY, IS, WE DON'T HAVE ANYMORE THE FOREIGN AGENT.

AND THIS HAS A VERY IMPORTANT ADVANTAGE.

THE COMMUNICATION WILL START THE SAME.

THE CORRESPONDENT HOST WILL TRY TO SEND THE INFORMATION TO MY HOME NETWORK.

THE HOME AGENT WILL SEND THAT INFORMATION STRAIGHT TO MY LAPTOP.

AND THEN I WILL BE ABLE TO GO BACK STRAIGHT TO THE CORRESPONDENT, AND IN ADDITION TO THAT, AFTER THE FIRST COMMUNICATION HAS BEEN SENT, THE CORRESPONDENT HOST WILL BE ABLE TO REPLY STRAIGHT TO ME.

NO NEED TO FOLLOW ANYMORE THE TRIANGLE ROUTING.

JUST FOR THE FIRST CONNECTION.

SO WHAT IS THE ADVANTAGE?

OBVIOUSLY, WE HAVE MUCH LOWER DELAY.

WE HAVE ALSO LESS BANDWIDTH BEING USED ACROSS DIFFERENT NETWORKS, BECAUSE WE CAN DO SOMEHOW A PEER-TO-PEER CONNECTION AFTER THE FIRST SESSION OR THE FIRST PACKET HAS BEEN SENT.

AND LAST, BUT NOT LEAST, IT MEANS IF I DON'T NEED TO HAVE A FOREIGN AGENT, I WILL NOT DEPEND ON WHICH NETWORK I AM CONNECTED TO.

IN IPV4, I CAN ONLY USE MOBILITY IF I HAVE SUPPORT FOR MOBILITY IN MY HOME NETWORK AND THERE IS SUPPORT FOR MOBILITY IN THE VISITED NETWORK.

IN IPV6, I JUST DEPEND ON MY OWN INFRASTRUCTURE, PROBABLY THE INFRASTRUCTURE OF MY ISP, BECAUSE MAYBE THE HOME NETWORK -- SORRY, THE HOME AGENT WILL NOT BE IN MY LOCAL AREA NETWORK, BUT IN THE ISP NETWORK.

IN FACT, IT'S VERY EASY TO SEE THAT MOBILE IPV4 HAS NOT ALMOST BEEN DEPLOYED COMMERCIALLY, BECAUSE THAT CIRCUMSTANCE.

I AM NOT GOING TO CHOOSE MY HOTELS WHEN I AM TRAVELING DEPENDING ON IF THEY HAVE SUPPORT FOR MOBILE IPV4 OR NOT.

OBVIOUSLY, THAT'S NOT GOING TO WORK.

IN FACT, I BELIEVE THERE IS ONLY ONE BIG CARRIER, WHICH IS KDDI FROM JAPAN, OFFERING MOBILE IPV4 SUPPORT.

I DIDN'T HEAR ABOUT ANYONE ELSE OFFERING THAT SUPPORT.

HOWEVER, IN IPV6, I REALLY THINK WE WILL SEE MORE AND MORE DEPLOYMENT OF MOBILITY.

AND AS YOU CAN GUESS, MOBILITY WILL BE PROBABLY KEY FOR THE DEVELOPMENT OF NEW APPLICATIONS, NEW SERVICES, AND WE WILL FOR SURE TAKE A LOT OF ADVANTAGE OF THAT FUNCTIONALITY IN THE NEXT SERIES OF COLLABORATIVE APPLICATIONS OR ALL KIND OF APPLICATIONS THAT REALLY CAN, SAY, TAKE ADVANTAGE OF THIS MOBILITY SUPPORT.

LAST THREE SLIDES.

WHILE ONE IMPORTANT THING, OBVIOUSLY, IS, WE ARE NOT GOING TO BREAK IPV4, AND, IN FACT, WE CANNOT SWITCH OFF INTERNET AND SAY, OKAY, LET'S DECIDE ON A COMMON DATE, 31ST OF DECEMBER, 2006, SWITCH OFF ALL INTERNET.

LET'S EVERYBODY UPGRADE THE NETWORK AND THEN KEEP GOING.

WE CANNOT STOP INTERNET.

THERE IS NO WAY.

THERE ARE MANY APPLICATIONS AND SERVICES WHICH DEPEND ON INTERNET, AND WILL BE A BIG MESS.

AND, IN ADDITION, IT'S IMPOSSIBLE TO REALLY GET EVERYONE, NOT JUST ISPS, BUT ALSO THE ENTERPRISES AND THE USERS, AGREEING ON A COMMON DATE AND TIME TO DO THAT TYPE OF UPGRADE.

SO SINCE WE STARTED DESIGNING IPV6, WE HAD THAT IN MIND ALL THE TIME.

AND WE DECIDED THAT WE REALLY NEED AN INCREMENTAL UPGRADE.

AND THAT'S WHAT WE CALL TRANSITION AND COEXISTENCE.

MANY PEOPLE SAY "MIGRATION."

I REALLY THINK "MIGRATION" IS WRONG TERMINOLOGY, BECAUSE IN MANY LANGUAGES, "MIGRATION" BRINGS THE CONNOTATION OF BREAKING SOMETHING AND GOING TO SOMETHING NEW.

AND THIS IS NOT WHAT WE ARE GOING TO DOING WITH IPV6, OR WHAT, ACTUALLY, WE ARE DOING SINCE PROBABLY THREE YEARS AGO.

WHAT WE ARE DOING IS ON TOP OF THE EXISTING IPV4 INFRASTRUCTURE, ADDING SUPPORT FOR IPV6.

SO WE WILL HAVE BOTH PROTOCOLS, IPV4 AND IPV6, COEXISTING FOR LONG TIME, MANY, MANY YEARS PROBABLY.

SO HOW WE DO THAT?

WELL, WE HAVE, BASICALLY, THREE SETS OF TRANSITION AND COEXISTENCE TECHNIQUES.

THE FIRST ONE IS WHAT WE CALL DUAL STACK.

BASICALLY, AS THE NAME ITSELF SAYS, WE HAVE AT THE SAME TIME SUPPORT FOR BOTH PROTOCOLS, FOR IPV4 AND FOR IPV6.

AND THIS IS SOMETHING NOT NEW, IT'S SOMETHING WE DID FOR MANY YEARS, WHICH ARE THE PROTOCOLS.

WE HAVE NETWORKS THAT STILL ARE RUNNING IPX, NETWORKS THAT RUN APPLETALK, AND MANY OTHER PROTOCOLS, AND ALSO RUN IPV4.

SO WHAT WE ARE DOING NOW IS ADDING TO THE IPV4 SUPPORT THE IPV6 ONE ALSO.

SO, IN FACT, TODAY, MOST OF THE OPERATING SYSTEMS ALREADY HAVE SUPPORT FOR IPV6 IN ADDITION TO SUPPORT FOR IPV4.

I GUESS MOST OF YOU ARE USING EITHER LINUX, MAC OS, XP, WINDOWS XP.

ALL THESE OPERATING SYSTEMS HAVE SUPPORT FOR IPV6.

IN SOME CASES, IT COMES ALREADY ENABLED.

FOR EXAMPLE, IN MAC OS, IN SOME RECENT VERSIONS OF LINUX OR BSD.

SOME OTHERS IS NOT ENABLED BY DEFAULT, LIKE, FOR EXAMPLE, THE CASE FOR XP.

BUT EVEN SOME APPLICATIONS CAN TURN ON WITHOUT THE USER NOTICING IT THE SUPPORT FOR IPV6 AND JUST GET IT WORKING.

AND, IN FACT, MANY USERS OF APPLICATIONS LIKE MESSENGER AND SOME OTHERS ARE USING IPV6 TODAY WITHOUT NOTICING IT.

AND EVEN WITHOUT OUR ISPS SUPPORTING IN A NATIVE WAY IPV6.

THE NEXT GENERATION OF VISTA, WHICH ACTUALLY HAS BEEN DELIVERED TO THE MARKET I THINK A COUPLE OF DAYS AGO, ALSO COMES WITH IPV6 ENABLED BY DEFAULT.

AND I GUESS THAT WILL CHANGE THE PICTURE OF THE UTILIZATION OF IPV6, BECAUSE MANY VISTA APPLICATIONS AND MANY MORE COMING IN THE NEXT MONTHS OR YEARS, WILL MAKE USAGE OF IPV6 AND TAKE ADVANTAGE OF THESE END-TO-END FUNCTIONALITIES.

SO THE QUESTION NOW IS, IF WE HAVE TWO PROTOCOLS AT THE SAME TIME, IPV4 AND IPV6, HOW WE ARE GOING TO DECIDE IF USING ONE OR THE OTHER.

WELL, WE TAKE ADVANTAGE OF DNS.

IN DNS, WE HAVE THE "A" RECORD TO REPRESENT THE IPV4 ADDRESSES, AND AT THE SAME TIME, NOW WE HAVE ALSO THE QUAD "A" RECORDS, WHICH STAND FOR THE IPV6 ADDRESSES.

SO WE HAVE A WEB SERVER THAT HAS SUPPORT FOR B4 AND B6, IT WILL HAVE BOTH "A" AND QUAD "A" RECORDS.

AND IF THE CLIENT TRYING TO ACCESS THAT WEB SERVER HAS ALSO SUPPORT FOR IPV6, HE WILL TRY FIRST WITH IPV6.

IF THAT FAILS, FOR WHATEVER REASON, THEN HE CAN DROP BACK, FALL BACK, TO IPV4.

SO, AGAIN, WE ARE NOT BREAKING ANYTHING.

WE ARE ADDING SUPPORT FOR IPV6 ON TOP OF THE EXISTING SUPPORT OF IPV4.

IT MAY HAPPEN THAT IN THE FUTURE, SOME HOST START, LET'S SAY, NOT HAVING SUPPORT FOR IPV4.

BUT I REALLY THINK THAT WILL TAKE LONG TIME TO HAPPEN.

AS YOU CAN GUESS ALSO, DOING THIS TRY FIRST WITH IPV6, IT MEANS THAT IN A SMOOTH WAY, WE ARE GOING TO USE MORE AND MORE IPV6 AS MUCH AS IS BECOMING AVAILABLE IN MORE SERVICES, WEB SERVERS, OR ANY KIND OF SERVERS IN GENERAL.

SECOND SET OF TRANSITION TECHNOLOGIES IS WHAT WE CALL TUNNELS.

AND TUNNEL IS, AGAIN, A CONCEPT THAT IT HAS BEEN USED SINCE A LONG TIME.

WE USE TUNNELS WHEN WE USE VPNS, VIRTUAL PRIVATE NETWORKS.

SO, BASICALLY, WHAT WE HAVE IS DIFFERENT KINDS OF WAYS OF DOING TUNNELS, OF IPV6 IN IPV4, SO WE ARE TRANSPORTING THE IPV6 PACKETS INSIDE IPV4, OR WE TRANSPORT IPV6 IN MPLS NETWORKS, AND DIFFERENT KINDS OF TRANSPORT TECHNOLOGIES.

SO THIS IS, AGAIN, A VERY, VERY SIMPLE WAY TO SUPPORT IPV6 ACROSS NETWORKS THAT MAYBE ARE NOT READY, FOR EXAMPLE, MAYBE MY ISP DOESN'T PROVIDE TO ME SUPPORT FOR NATIVE IPV6, BUT I CAN ALWAYS USE A TUNNEL TO REACH IPV6 NETWORKS.

SO THAT'S A VERY SIMPLE WAY TO DO THAT, AND, IN FACT, MANY OF THE ACCESS NETWORKS TODAY ARE STILL NOT REALLY SUPPORTING IPV6 YET.

MORE OF -- MOST OF THE CORE NETWORKS, THE BIG BACKBONES OF THE LARGE CARRIERS, ALREADY SUPPORT IPV6.

BUT IT'S NOT THE CASE YET FOR MANY OF THE SMALL AND MEDIUM ISPS.

AND THE LAST SET, WHICH MY SUGGESTION ALWAYS IS, DON'T USE IT UNLESS IT'S REALLY NECESSARY, IS TRANSLATION.

TRANSLATION, IT'S A KIND OF NAT, AS WHAT WE USE TODAY WITH IPV4, BUT WE ARE TRANSLATING NOT JUST ADDRESSES, BUT ALSO THE PROTOCOL.

WE HAVE ON ONE SIDE ONLY IPV4; ON THE OTHER SIDE, ONLY IPV6.

AND WE HAVE A BOX THAT IS DOING THE TRANSLATION OF THE INFORMATION BETWEEN BOTH PROTOCOLS.

OBVIOUSLY, A TRANSLATION IS NEVER PERFECT, AND THAT MEANS WE CAN MISS INFORMATION WHEN TRANSLATING FROM IPV6 TO IPV4 OR VICE VERSA.

SO SOMEHOW, IT WORKS, BUT WITH SOME RESTRICTIONS.

AND IT WORKS VERY WELL FOR VERY SIMPLE PROTOCOLS LIKE, FOR EXAMPLE, HTTP, TO (INAUDIBLE) WEB PAGES AND SO ON.

BUT IT'S NOT THAT EASY IN THE CASE OF OTHER MORE COMPLEX PROTOCOLS.

WHY WE DON'T NEED MOST OF THE TIME TO USE TRANSLATION?

BECAUSE IF WE KEEP USING DUAL STACK, WHICH IS THE FIRST AND VERY BASIC RECOMMENDATION, WE WILL HAVE BOTH PROTOCOLS.

SO IF WE HAVE BOTH PROTOCOLS, WE NEVER NEED TO DO A TRANSLATION, BECAUSE WE WILL ALWAYS BE ABLE TO TALK WITH BOTH IPV4 ONLY AND IPV6 ONLY HOST.

AND WITH THAT, FINISH THIS PART.

SOME TIME FOR QUESTIONS.

I TRIED TO GO SLOWLY, TO MAKE EVERYTHING EASY.

BUT IT MAY BE NEEDED SOME CLARIFICATION?

NOT REALLY?

YEAH, ONE.

>> (INAUDIBLE).

>>JORDI PALET: SWITCH ON.

>> IT SEEMS YOU WERE TERRIFIC.

SO NO MORE QUESTIONS.

THANK YOU.

>>JORDI PALET: YEAH.

OKAY.

SO YOU NEED A CABLE, SEBASTIAN?

>>CHRISTIAN O'FLAHERTY: MY NAME IS CHRISTIAN O'FLAHERTY, AS JORDI SAID BEFORE.

OKAY.

SO GOOD AFTERNOON, AND I AM GOING TO MAKE A PRESENTATION TALKING ABOUT THE POLICIES THAT ARE APPLIED FOR, IN PARTICULAR, FOR IPV6 AND THE DIFFERENCES OF THE POLICIES IN DIFFERENT REGIONS.

I AM GOING TO DESCRIBE THE STRUCTURE AND THE -- HOW THE REGISTRIES WORK.

I'M GOING TO DETAIL THREE POLICIES THAT ARE VERY IMPORTANT FOR THE IPV6 DEPLOYMENT.

THESE ARE THE INITIAL ALLOCATION, HOW A PROVIDER CAN GET THE IPV6 ADDRESSES FROM THE REGISTRY HE BELONGS TO.

HOW SUBSEQUENT ALLOCATIONS ARE GOING TO BE MADE TO PROVIDERS.

AND HOW IT'S MANAGED THE CRITICAL INFRASTRUCTURE THAT IS NEEDED TO SUPPORT THE IPV6 OPERATION.

I'M GOING TO DESCRIBE THE DISCUSSIONS THAT ARE BEING -- TAKING PLACE DURING THESE DAYS ON THE PUBLIC POLICY LISTS OF EACH REGISTRY.

AND AFTER THAT, SEBASTIAN IS GOING TO TALK ABOUT THE GLOBAL POLICIES FOR IPV6.

SO WHAT ARE THE REGISTRIES?

IN ORDER TO GET IPV4 OR IPV6 RESOURCES AND ALSO AUTONOMOUS SYSTEM NUMBERS, THE PROVIDERS SHOULD ASK OR SHOULD REQUIRE TO THESE REGISTRIES THAT ARE REGIONAL REGISTRIES FOR THESE RESOURCES.

WE HAVE THE AFRINIC REGISTRY IN AFRICA, APNIC IN ASIA-PACIFIC.

WE HAVE ARIN IN NORTH AMERICA, LACNIC IN SOUTH AMERICA AND CARRIBEAN, AND RIPE NCC IN EUROPE AND PART OF ASIA.

AND MIDDLE EAST.

NOW I'M GOING TO REVIEW THE POLICIES IN EACH REGISTRY.

I HAVE THE TEXT OF EACH POLICY.

AND AFTER THAT, I'M GOING TO SHOW YOU A COMPARISON OF ALL OF THEM.

SO I'M NOT GOING TO MAKE A DETAILED DESCRIPTION OF EACH ONE, BECAUSE MOST OF THEM ARE EXACTLY THE SAME.

THE FIRST IMPORTANT POLICY IS HOW A PROVIDER CAN REQUEST IPV6 ADDRESSES FROM THE REGISTRY.

AND IN PARTICULAR FOR AFRINIC, THE SIZE OF THE FIRST BLOCK THAT IS ASSIGNED TO THE PROVIDERS, SORT OF THE LIR, THAT'S LOCAL INTERNET REGISTRY, THE SIZE, IT'S /32.

IF YOU REMEMBER FROM JORDI'S PRESENTATION, THE I.P. ADDRESSES WERE SPLIT INTO 64 PARTS.

SO THIS INITIAL ALLOCATION, IT'S FOR -- OR IT'S ENOUGH FOR MOST OF THE PROVIDERS, BECAUSE YOU HAVE 32 BITS TO ADDRESS NETWORKS.

THAT IS A LOT OF SPACE.

IT'S THE COMPLETE IPV4 SPACE THAT YOU WILL RECEIVE IN -- ON THE INITIAL ALLOCATION.

IN ORDER TO GET THIS INITIAL ALLOCATION, YOU SHOULD SHOW A REASONABLE PLAN FOR MAKING /48 IPV6 ASSIGNMENTS TO END SITES WITHIN 12 MONTHS.

THE LIR, WHICH IS THE ISP REQUIRED FOR ADDRESS, SHOULD ALSO PLAN TO ANNOUNCE THE ALLOCATION AS A SINGLE AGGREGATED BLOCK IN THE INTERDOMAIN ROUTING SYSTEM WITHIN 12 MONTHS.

AND THIS IS THE PROVIDER THAT IS REQUIRING FOR THESE IPV6 ADDRESSES, IT'S GOING TO ANNOUNCE IN THE BCP, OR USING BCP BEFORE THESE NETWORKS THAT ARE GOING TO BE RECEIVED BY THE REGISTRY.

AND HE SHOULD ANNOUNCE THEM WITHIN 12 MONTHS.

AND IN ORDER TO RECEIVE THESE NETWORKS, HE SHOULD SHOW A DETAILED PLAN TO PROVIDE IPV6 CONNECTIVITY TO ORGANIZATIONS IN THE REGION, THAT IS, AFRICA.

SO THEY HAVE TO ASSIGN THE IPV6 TO THEIR CUSTOMERS, THEY HAVE TO CONNECT THEIR NETWORK TO THE GLOBAL INTERNET ROUTING TABLE, AND HE SHOULD ALSO PROVIDE SERVICES TO THE CUSTOMERS HE HAS.

ON ARIN, THERE ARE A FEW DIFFERENCES.

THE SIZE, IT'S EXACTLY THE SAME, /32 OR A BIGGER NETWORK.

MUST BE AN LIR.

THE PROVIDER HAS TO PLAN TO PROVIDE IPV6 CONNECTIVITY TO ORGANIZATIONS TO WHICH THEY WILL ASSIGN THE IPV6 ADDRESS SPACE BY ADVERTISING THAT CONNECTIVITY THROUGH ITS SINGLE AGGREGATED ADDRESS ALLOCATION.

IT'S NOT MENTIONED THE TIME PERIOD WHERE -- WHEN THIS ANNOUNCEMENT SHOULD BE DONE.

THE PROVIDER MUST BE AN EXISTING KNOWN ISP IN THE ARIN REGION OR HAVE A PLAN TO MAKE AT LEAST 200 /48 ASSIGNMENTS TO OTHER ORGANIZATIONS.

AND ORGANIZATIONS CAN RECEIVE A BIGGER I.P. ADDRESS SPACE THAN A /32.

ON RIPE, ON EUROPE AND PART OF ASIA, THE SIZE IS EXACTLY THE SAME AS BEFORE.

IT MUST BE A SERVICE PROVIDER, NEED A PLAN TO SHOW HOW IS IT GOING TO PROVIDE IPV6 CONNECTIVITY TO ORGANIZATIONS ASSIGNING /48S TO THEM.

THE SAME REQUIREMENT AS BEFORE ON ARIN, THAT HAVE A PLAN FOR MAKING AT LEAST 200 /48 ASSIGNMENTS.

AND THE OTHER ONES ARE PRETTY SIMILAR AS BEFORE.

ON ASIA-PACIFIC, MOST OF THE RULES ARE THE SAME, BUT IN ADDITION, THEY HAVE -- THEY LET A PROVIDER TO RECEIVE AN ALLOCATION IF THEY HAVE A CLOSED NETWORK.

THAT IS AN EXCEPTION, THEY DON'T REQUIRE THE PROVIDER TO ANNOUNCE THE BLOCK USING BCP TO THE GLOBAL TABLE IF IT'S NOT NEEDED.

IN LATIN AMERICA AND KOREA, THE SIZE IS THE SAME, /32.

MUST BE A SERVICE PROVIDER, NOT AN END SITE.

MUST DOCUMENT A DETAILED PLAN FOR THE SERVICES AND IPV6 CONNECTIVITY TO BE OFFERED TO OTHER ORGANIZATIONS.

THERE'S NO -- IT DOESN'T MENTION ANYTHING ABOUT THE AMOUNT OR THE SIZE OF THE ALLOCATIONS.

THE PROVIDER MUST ANNOUNCE A SINGLE BLOCK IN THE INTERNET INTERDOMAIN ROUTING SYSTEM WITHIN A PERIOD NO LONGER THAN 12 MONTHS.

AND THEY SHOULD OFFER IPV6 SERVICES TO THE CUSTOMERS PHYSICALLY CONNECTED OR PHYSICALLY LOCATED WITHIN THE REGION COVERED BY LACNIC WITHIN A PERIOD OF TIME NO LONGER THAN 24 MONTHS.

SO THIS IS A COMPARISON, A SIMPLE COMPARISON OF DIFFERENT REGIONS AND THE MOST IMPORTANT REQUIREMENTS.

THE ELIGIBILITY, THAT IT'S THE REQUIREMENT FOR THE PROVIDER IN ORDER TO GET THE INITIAL ALLOCATIONS.

THERE ARE SLIGHT DIFFERENCES, LIKE THE PLAN THAT SHOULD MAKE IN ORDER TO GET THESE ALLOCATIONS, ONE REQUIRES 12-MONTH PLAN.

ARIN AND RIPE, FOR EXAMPLE, ARE REQUIRED AT LEAST 200 /48 ASSIGNMENTS DURING THIS PERIOD.

FOR RIPE, IT'S TWO YEARS.

FOR ARIN, IT'S FIVE YEARS.

AND THAT'S IT.

THERE ARE POLICIES THAT IT'S VERY IMPORTANT, IT'S HOW A PROVIDER CAN REQUEST ADDITIONAL ADDRESS SPACE WHEN THE PREVIOUS ALLOCATION IS EXHAUSTED.

THE -- IT'S A SUMMARY, BECAUSE MOST OF THE POLICIES IN EACH REGION ARE THE SAME.

FOR AFRINIC, ASIA-PACIFIC, RIPE, AND LACNIC, THE SIZE OF THE ALLOCATION, OF THE SECOND OR SUBSEQUENT ALLOCATIONS, THE MINIMUM SIZE OF NEXT ALLOCATION WILL BE EQUAL TO THE FIRST ALLOCATION SIZE UNLESS THERE'S SOME JUSTIFICATION FOR A LARGER BLOCK.

IN ORDER TO RECEIVE THIS ADDITIONAL ALLOCATION, THE ISP MUST SATISFY THE EVALUATION THRESHOLD OF PAST ADDRESS UTILIZATION.

THE ADDRESSES ARE ALREADY ALLOCATED TO THE PROVIDER SHOULD HAVE BEEN ALLOCATED OR USED FOR CUSTOMERS, AND THERE'S A DIFFERENCE BETWEEN IPV4 AND IPV6 ON HOW THIS IS MEASURED.

ON IPV4, THERE IS A REQUIREMENT TO SHOW THAT 80% OF THE ALLOCATIONS OR ON THE ADDRESS BLOCK THAT WAS ASSIGNED TO THE PROVIDER WAS ALLOCATED TO CUSTOMERS.

ON IPV6, A MORE EFFICIENT WAY IS USED TO SEE HOW THIS USAGE IS BEING DONE, BECAUSE ON VERY LARGE NETWORKS, USING A PERCENTAGE OF THE ALLOCATED NETWORK RESOURCES, IT'S NOT FAIR, BECAUSE IT'S VERY DIFFICULT TO HAVE THIS EFFICIENCY.

WHEN YOU HAVE A PRETTY SMALL NETWORK, YOU CAN REACH THE 80 OR 90% OF EFFICIENCY.

BUT ON VERY LARGE NETWORKS, THE COMPLEXITY OF THE NETWORK MAKES VERY DIFFICULT TO ACHIEVE THE 80% OF EFFICIENCY.

SO THE HD-RATIO USED, THIS IS A FORMULA THAT TRIES TO MATCH OR TO BE MORE FAIR CONSIDERING THE SIZE OF THE NETWORK.

IN THE CASE OF THOSE REGISTRIES, THE HD-RATIO USED, THE VALUE OF THE FORMULA, IT'S 0.8.

AND WHEN THIS UTILIZATION, THIS THRESHOLD IT'S SURPASSED, THE PROVIDER CAN GET ADDITIONAL I.P. ADDRESSES.

ON THE ARIN REGION, THE POLICIES ARE SIMILAR, WITH A COUPLE OF EXPECTATIONS.

THE ISP MUST SATISFY THE EVALUATION THRESHOLD OF PAST ADDRESSES UTILIZATIONS, BUT USING UNITS OF /56.

ON THE PREVIOUS POLICY DESCRIBED, THE UNITS USED IN THE FORMULA FOR THE CALCULATION ARE IN /48.

AND THE VALUE USED ON ARIN FOR THE FORMULA IN ORDER TO GET ADDITIONAL ADDRESS SPACE, IT'S 0.94.

AND THE LAST POLICY TO BE DESCRIBED AND THAT IT'S AVAILABLE ON ALL THE REGIONS, IT'S THE ONE APPLIED FOR CRITICAL INFRASTRUCTURE.

AND, FOR EXAMPLE, IN ASIA-PACIFIC, THE DEFINITION OF THIS CRITICAL INFRASTRUCTURE, IT'S WHEN IS IT USED FOR ROOT DNS, COUNTRY CODE TOP-LEVEL DOMAINS, GENERIC TOP-LEVEL DOMAINS, IANA, FOR THE RIRS ITSELF, FOR -- AND FOR NIRS.

THE MINIMUM IS /32.

THAT IS THE SAME AS BEFORE.

THERE IS A PARTICULAR CONSIDERATION FOR INTERNET EXCHANGE POINTS.

AND THEY WILL BE ABLE TO RECEIVE A /48.

IN ORDER TO GET THESE RESOURCES TO BE USED FOR CRITICAL INFRASTRUCTURE, THE RESOURCES ARE GOING TO BE AVAILABLE ONLY TO THE ACTUAL OPERATORS OF THE NETWORK INFRASTRUCTURE PERFORMING SAID FUNCTIONS, THE ONES I'VE MENTIONED BEFORE.

ON ARIN, THIS POLICY IS KNOWN AS MICROALLOCATIONS POLICY.

THE USAGE IS SIMILAR TO THE OTHER REGIONS.

THE SIZE, IT IS DIFFERENT.

THEY ASSIGN A /48 FOR THAT PURPOSE.

AND THE SAME, ASSIGNMENTS TO CRITICAL INFRASTRUCTURE ARE AVAILABLE ONLY TO THE ACTUAL OPERATORS OF THE NETWORK INFRASTRUCTURE PERFORMING SUCH FUNCTIONS.

IN THE LACNIC REGION, THE SITES CAN BE EITHER A /48 OR A /32.

AND THE EXPECTATION IS THAT FOR INTERNET EXCHANGE POINTS, THEY MUST HAVE A CLEAR AND OPEN POLICY FOR OTHERS TO SHOW THE EXCHANGE POINT, AND MUST HAVE AT LEAST THREE MEMBERS.

IN THE RIPE NCC REGION, THE USAGE IS -- THEY ARE NOT INCLUDING EXCHANGE POINTS, BUT THEY ARE INCLUDING ROOT DNS, ANYCASTING TOP-LEVEL DOMAINS.

THE DIFFERENCES ARE ON THE SIZE OF THE ALLOCATION FOR EACH ONE.

IN THE CASE OF ROOT DNS, THE SAME ALLOCATION THAT IS THE MINIMUM ALLOCATION FOR PROVIDERS IS GOING TO BE USED.

FOR TOP-LEVEL DOMAINS, /48 IS GOING TO BE ALLOCATED.

AND FOR INTERNET EXCHANGE POINTS, CAN BE EITHER A /48 OR 64.

THERE'S A POLICY FOR END USERS.

IT'S ONLY AVAILABLE ON THE ARIN REGION.

AN END USER IN NORTH AMERICA WILL RECEIVE A /48.

AND IT'S USED NOT FOR PROVIDERS, BUT FOR END SITES.

AND IF YOU QUALIFY FOR AN IPV4 ADDRESS ALLOCATION, YOU WILL BE ABLE TO RECEIVE AN IPV6 PREFIX AS AN END USER.

WHAT ARE THE POLICIES BEING DISCUSSED THAT IS ON THE PUBLIC LIST OF EACH REGISTRY?

WELL, THERE ARE SOME SUGGESTIONS IN ORDER TO REMOVE THE REQUIREMENTS OF THE AMOUNT OF INITIAL ALLOCATIONS THAT A PROVIDER PLANNED TO DO TO THEIR CUSTOMERS.

THERE'S A PROPOSAL ALSO TO REMOVE THE REFERENCE TO A /48 OR ANY OTHER ALLOCATION SIZE ON THE INITIAL ALLOCATION REQUEST.

THE VALUE ON THE HD-RATIO, IT'S BEING DISCUSSED, BECAUSE 0.8 CAN MAKE A VERY INEFFICIENT USE OF THE RESOURCES.

SO A BIGGER VALUE. .94 IS BEING USED IN ARIN FOR EXAMPLE. IT'S GOING TO BE MORE APPROPRIATE.

THERE WERE SOME SUGGESTIONS TO USE /32 FOR THOSE NETWORKS THAT WOULD LIKE TO RECEIVE PROVIDER INDEPENDENT IP ADDRESSES. AND THERE ARE SOME SUGGESTIONS TO LET NEW ORGANIZATIONS TO RECEIVE IPV6 ADDRESSES AND NOT BE -- THE IDEA IS NOT TO REQUIRE THEM TO BE AN OPERATOR, BECAUSE PERHAPS A NEW PROVIDER WOULD LIKE TO INITIATE THEIR OPERATION, THEIR BUSINESS ONLY WITH IPV6.

SO SOME RULES IN PARTICULAR IN THE ARIN REGION SHOULD BE MODIFIED TO LET THESE PROVIDERS RECEIVE IPV6 ADDRESSES.

NOW THE LAST TOPIC OF OUR AGENDA WAS THE GLOBAL POLICY PROCESS, AND I WOULD LIKE SEBASTIAN TO PRESENT THEM.

>>SEBASTIAN BELLAGAMBA: THANK YOU. I WILL MAKE IT SHORT BECAUSE WE DON'T HAVE PLENTY OF TIME.

SO CHRISTIAN VERY WELL DESCRIBED HOW POLICY DEVELOPMENT PROCESS WORKS OR THE CONSEQUENCES OF THE PDP IN EVERY RIR REGION.

SO I WILL FOCUS IN ONE PARTICULAR POLICIES THAT ARE THE GLOBAL POLICIES. THE POLICIES THAT ARE SET, BECAUSE SOME GLOBAL COORDINATION IS NEEDED IN SOME CASES.

FOCUSING ON IPV6, THERE IS JUST ONE GLOBAL POLICY.

A GLOBAL POLICY HAS THREE CHARACTERISTICS. A GLOBAL POLICY SHOULD -- HAS TO INVOLVE ALL FIVE RIRS; HAS A COMMON TEXT FROM EVERY SINGLE RIR EMERGED, A SINGLE TEXT FROM EVERY REGION, AND HAS TO INVOLVE IANA, BASICALLY, PLUS THE FIVE RIRS.

I MEAN, THERE IS NO -- IT'S NOT A GLOBAL POLICY IF THE POLICIES, THE REGIONAL POLICIES IN EVERY SINGLE RIR ARE THE SAME, AND DOES NOT INVOLVE IANA.

AS I SAID, THERE'S JUST ONE GLOBAL POLICY, AND IT'S THE ONE DEALING WITH THE ALLOCATION OF IPV6 ADDRESS BLOCKS FROM IANA TO THE RIRS.

THIS POLICY HAS BEEN RATIFIED RECENTLY. IT'S BEEN RATIFIED BY THE ICANN BOARD IN SEPTEMBER 7TH, 2006.

I WILL GIVE YOU AN IDEA OF HOW THE GLOBAL POLICY DEVELOPMENT PROCESS WORKS. AS YOU MAY KNOW, ALL THE ICANN COMMUNITY, AND SPECIFICALLY THE RIR COMMUNITIES, THE ADDRESSING COMMUNITY WORKS IN A BOTTOM-UP MANNER. YOU WILL SEE HOW IT WORKS HERE FOR THE GLOBAL PDP -- FOR THE GLOBAL POLICIES.

THE REGIONAL COMMUNITIES, EACH ONE OF THE RIRS HAD AN IDEA AND PROPOSED A NEW POLICY.

AS I SAID, FOR BEING A GLOBAL POLICY, A COMMON TEXT SHOULD EMERGE IN EVERY SINGLE FIVE RIR COMMUNITIES.

WHEN THE TEXT IS SET BY THE FIVE RIRS, IT GOES TO THE ADDRESS COUNCIL IN THE ADDRESS SUPPORTING ORGANIZATION HERE IN ICANN. AND THE ADDRESS SUPPORTING ORGANIZATION, THE ADDRESS COUNCIL SETS -- SORRY, AUDITS THAT EVERY SINGLE STEP IN THE PDP HAS BEEN SET, SO DELIVERS THE POLICY TO THE ICANN BOARD FOR RATIFICATION.

BUT THE IMPORTANT THING HERE IS THE BOTTOM-UP PROCESS IS BEING FOLLOWED.

THIS IS THE EXPLANATION WITH MORE DETAIL OF WHAT MEANS THE GLOBAL POLICY FOR IPV6.

SETS WHAT'S THE MINIMUM ALLOCATION SIZE FOR THE IPV6 BLOCKS. AND WHAT'S THE ALLOCATION CRITERIA FOR ALLOCATING NEW BLOCKS TO AN RIR. YOU CAN SEE THE MINIMAL ALLOCATIONS EQUALS 18 MONTHS OF NECESSARY SPACE. THE UNIT SIZE OF THE MINIMUM ALLOCATION IS /12. AS CHRISTIAN SAID, REMEMBER MOST OF THE RIRS ARE ALLOCATING /32S TO THE ISPS. IANAS ARE ALLOCATING A /12 TO THE RIRS. THAT IS WHAT IT MEANS.

FOR BEING -- FOR DEMONSTRATING THE NEED OF A NEW ALLOCATION YOU NEED TO SET ONE OF THESE CRITERIAS. THE AVAILABLE SPACE, THE AVAILABLE BLOCK IS LESS THAN 50% OF /12, OR YOU PROVE THAT THE NECESSITY, THE AVAILABLE SPACE DOES NOT COVER THE NECESSITY FOR THE NEXT NINE MONTHS. OR EXISTS A SPECIAL NEED.

THERE IS A PROVISION FOR THE FIRST ALLOCATION. THE FIRST ALLOCATION IS A /12 -- WAS /12 WAS ALLOCATED IN OCTOBER FROM IANA TO THE RIRS. AND EVERY SINGLE OF THE FIVE RIRS GOT A /12 FROM IANA AT THAT POINT.

AND THERE IS A REQUIREMENT FOR ANNOUNCEMENT. I MEAN, EVERY SINGLE ALLOCATION SHOULD BE PUBLIC. THAT'S WHAT THE ANNOUNCEMENTS MEANS.

WHEN IANA ALLOCATES A BLOCK TO AN RIR, IT SHOULD BE ANNOUNCED PUBLICLY, AND EVERY SINGLE MAILING LIST ANNOUNCED THE FACT. AND WHEN AN RIR ALLOCATES TO AN ISP, IT'S ANNOUNCED AGAIN.

THE NEXT, PLEASE.

IN THIS CASE, THE -- I WILL HIGHLIGHT SOME FACTS ABOUT THE IPV6 GLOBAL ALLOCATION POLICY.

THE MINIMUM ALLOCATION SIZE MAKES IT THAT THE ALLOCATION DOES NOT DEPEND ON THE MARKET SIZE ITSELF. CONTRIBUTES TO REGIONAL AGGREGATION, BECAUSE EVERYONE GETS THE SAME BLOCK. SO AGGREGATING IS ONE OF THE BIG CHALLENGES OF ROUTING IP ADDRESSES.

AND IT'S THE BEST SIZE, /12, TO CONSERVE ADDRESS SPACE.

THE ALLOCATION CRITERIA PROVIDES OBJECTIVITY BECAUSE YOU HAVE A ROLE, A KNOWN ROLE BY EVERYONE. AND IT HAS TO SATISFY A DEMONSTRATED NEED AND PROVIDES ACCOUNTABILITY.

SO THIS IS THE HIGHLIGHTS OF THE POLICY WE SET THIS YEAR FOR ALLOCATING IPV6 ADDRESS SPACE FROM IANA TO THE RIRS.

THANK YOU VERY MUCH.

QUESTIONS OR COMMENTS OR....

>>ROQUE GAGLIANO: HELLO? HI. I AM ROQUE GAGLIANO FROM URUGUAY. ONE THING YOU MENTIONED IS THE CRITERIA FOR THE RIRS TO CHOOSE, SELECT, THE INITIAL ALLOCATION SPACE. IN THAT CASE, RIPE AND APNIC, THEY HAVE A DIFFERENT POLICY THAN THE OTHER TWO BECAUSE THEY USE A HD RADIO TO CALCULATE FIRST ALLOCATION SIZE, AND THAT HAS GENERATED THE LAST COUPLE OF YEARS HUGE ALLOCATION SIZE IN THAT REGION COMPARED WITH THE OTHER, THE REST.

AND MAYBE IN CONTROVERSIALLY GETTING THE FACT THAT WE ARE SUPPOSED TO BE RULED BY THE RFC2050 SLOW START DOCUMENT.

THE OTHER ISSUE THAT IS IMPORTANT TO KNOW IS THE CHARGE FOR THE IP ADDRESSES. WE ARE NOW IN THE TESTING PROCESS AND RIRS ARE NOT CHARGING RIGHT NOW, BUT THERE ARE GOING TO BE MAYBE SOME CHARGE AND THE POLICIES ON THE GAP FOR 32 OR MORE THAN 32 AND THE TEN-PLUS DIFFERENCE.

THANK YOU.

>>CHRISTIAN O'FLAHERTY: FORTUNATELY, THE CHARGES ARE NOT PART OF THE POLICY DEVELOPMENT PROCESS. AND EACH REGISTRY HAS ITS OWN ADMINISTRATIVE RULES AND CHARGE THE IPV6 ALLOCATION DIFFERENTLY.

THERE ARE CASES LIKE -- I KNOW, BECAUSE IT'S MY ORIGIN, BUT LACNIC, IT'S NOT CHARGING THIS ALLOCATION NOWADAYS. AND I KNOW RIPE -- RIPE IS CHARGING AND IT'S THE ONLY ONE, APPARENTLY.

>>JORDI PALET: REGARDING YOUR COMMENT ABOUT THE INITIAL ALLOCATIONS, I THINK THAT HAPPENED INITIALLY IN RIPE AND APNIC, I BELIEVE. I DON'T REMEMBER RIGHT NOW ANY OTHER BIG ALLOCATION IN ARIN OR AFRINIC. THERE ARE BIG ALLOCATIONS ALSO IN LACNIC,, A COUPLE OF THEM, BUT ACTUALLY THEY ARE ONLY /28 AND 29, I THINK.

AND MY VIEW ON THAT IS BASICALLY IT HAPPENED BECAUSE THE REQUESTERS JUSTIFIED THE NEED FOR THOSE BIGGER LOCATIONS. I THINK THAT'S THE REASON.

SO I DON'T SEE THAT'S DANGEROUS, AND I STILL BELIEVE IN THE SLOW START. BUT IF YOU HAVE AN ISP WHICH HAS, LET'S SAY, 5 MILLION USERS, WHY NOT SEE THAT ISP SHOULD GET, SINCE THE BEGINNING, ADDRESSES FOR ALL THOSE USERS. IT'S MY POINT OF VIEW, AND I THINK IT'S THE CRITERIA BEING USED IN THE DIFFERENT POLICIES, ALSO. THAT THE STAFF OF THE REGISTRIES SHOULD DEVELOP THAT CASE AND GIVE THEM THE SPACE IF NEEDED.

I'M NOT SURE IF THAT WAS YOUR POINT.

>>SEBASTIAN BELLAGAMBA: LET ME ADD SOMETHING, PLEASE.

>>ROQUE GAGLIANO: I AM TOTALLY COOL WITH THAT. I AM SAYING TO USE THE HD RADIO TO CALCULATE THE SIZE OF THE ALLOCATION BECAUSE HD RADIO IS NOT BASED ONLY ON THE ACTUAL CUSTOMERS YOU HAVE, BUT YOU APPLY THE LOG FORMULA. BUT I AM FINE WITH HAVING 2825, BUT NOT THE HD RADIO.

>>SEBASTIAN BELLAGAMBA: ALL THE ALLOCATIONS MADE IN THE IPV6, THE MINIMUM ALLOCATION SIZE IS WHAT CHRISTIAN PRESENTED. THERE ARE BIGGER ALLOCATIONS, BECAUSE THERE WAS JUSTIFIED BY THE NEED OF THE ISP.

ALL THE ALLOCATIONS WERE MADE ACCORDING THE LOCAL POLICIES AND THE REGIONAL POLICIES, AND THE REGIONAL POLICY DEVELOPMENT PROCESS IS AN OPEN AND TRANSPARENT PROCESS.

SO, I MEAN, WE CAN AUDIT HOW THE ALLOCATIONS WERE MADE OR JUSTIFIED, AND WE CAN SEE THAT IF WE DON'T LIKE THE POLICY THAT JUSTIFIES THAT ALLOCATION, WE CAN JUST SIMPLY CHANGE IT BECAUSE WE ARE THE ADDRESS SUPPORTING ORGANIZATION. WE ARE THE ADDRESSING COMMUNITY.

SO THE PDP IS OPENING AND YOU ARE ALL INVITED TO JOIN THE MAILING LIST OF EVERY RIR.

>>NIGEL CASSIMIRE: HI, MY NAME IS NIGEL CASSIMIRE FROM THE CARIBBEAN TELECOMMUNICATIONS UNION. I AM A BIT OF A NOVICE AT THIS SO MINE IS A SIMPLE QUESTION. I DON'T UNDERSTAND THE ALLOCATION UNIT YOU ARE TALKING ABOUT, /12, /54 AND SO ON. SO IF I CAN GET AN EXPLANATION OF WHAT THAT MEANS, I WOULD BE GRATEFUL. THANK YOU.

>>SEBASTIAN BELLAGAMBA: IT'S -- I WILL -- I AM NOT -- I AM THE ONLY ONE THAT IS NOT ENGINEERING IN THIS TABLE, SO I WILL TRY TO DO THE SIMPLE ANSWER.

YEAH, BECAUSE YOU KNOW THE GUYS WILL COMPLICATE IT.

YOU HAVE "N" BITS IN AN ADDRESS. SO IF YOU COUNT HOW MANY BITS YOU ARE ALLOCATING, YOU CUT THE WHOLE BITS. YOU SEE THE IPV4 ADDRESS, OKAY, IT'S THREE GROUPS OF NUMBERS, DECIMAL NUMBERS; OKAY?

OKAY. SO IF YOU GIVE THE LAST BITS TO -- IF YOU ALLOCATE TO AN ISP OR END USER THE LAST BIT, IT'S EIGHT BIT -- SORRY, THE LAST GROUP IS EIGHT BITS.

SO YOU ARE CUTTING THE ADDRESS BY 24 BITS THE REMAINING FROM THE 32 THAT IPV4 HAS.

SO YOU ARE GIVING A SLASH, CUTTING, 24 BECAUSE YOU ARE GIVING AWAY EIGHT BITS TO ALLOCATE BY ISP; OKAY?

THAT IS HOW IT WORKS, IN SIMPLE WORDS.

THEY CAN COMPLICATE AND TALK A LOT ABOUT THAT.

>>CHRISTIAN O'FLAHERTY: NO, IT'S GOING TO BE SIMPLE. THE NUMBERS INVOLVED ARE THE ONE THAT AN END SITE WILL RECEIVE. I'M SORRY.

FIRST, THE /64, IT'S GOING TO BE THE ADDRESS SPACE FOR A SINGLE CONNECTION, LOCAL NETWORK, IS ALWAYS GOING TO BE A /64.

THEN YOU HAVE A /48 OR 56. AS I MENTIONED, THERE ARE DIFFERENCES IN THE POLICY. AND THIS IS THE RECOMMENDED SIZE FOR A NETWORK TO BE ALLOCATED TO END SITE.

SO IF YOU ARE AN ISP, IF YOU ARE A PROVIDER, AND A CUSTOMER REQUIRES SPACE FROM YOU, YOU WILL ALLOCATE, YOU WILL ASSIGN FROM YOUR BIG ADDRESS CHUNK, FROM YOUR BIG ADDRESS BLOCK, AS LARGE 48, FOR EXAMPLE.

THE OTHER SIZE INVOLVED IN THESE POLICIES IS THE /32. THIS IS THE RECOMMENDED ANNOUNCEMENT ON THE BCP TABLES. THAT'S WHY THE REGISTRIES ASSIGN /32STO THE ISPS OF THE REGION BECAUSE THEY LIKE TO HAVE US LESS ENTRIES IN THE TABLE AS POSSIBLE, SO WE PREFER TO MAKE ALLOCATIONS OF BIG IP NETWORK BLOCKS AND REQUIRE THEM TO ANNOUNCE THESE BIG PREFIXES THE /32 ON THE BCP TABLE.

AND THE LAST ONE IS THE /12. THAT'S THE AMOUNT OF NETWORKS THAT EACH REGISTRY WILL RECEIVE IN ORDER TO ALLOCATE THEM AS /32S TO THEIR LIRS OF THE REGION.

>>JORDI PALET: ANY ADDITIONAL QUESTIONS?

>>PAULOS NYIRENDA: PAULOS NYIRENDA FROM MALAWI.

I WANTED TO KNOW THE STABILITY OF THE POLICY ON PRICE. THE RIRS DON'T CHARGE -- WELL, AFRINIC DOES NOT CHARGE, FOR EXAMPLE, NOW. HOW LONG IS THIS GOING TO BE, AND IS THERE DISCUSSION OF A TRANSITION TO PRICING?

AND I HAD ANOTHER QUESTION ON MARKET SIZE. I WANT TO UNDERSTAND HOW THE POLICY ON MARKET SIZE, THE FACT THAT THE ALLOCATIONS DON'T DEPEND ON MARKET SIZE, HOW WAS THIS ARRIVED AT AND WHAT WAS THE JUSTIFICATION?

>>CHRISTIAN O'FLAHERTY: I'M GOING TO TALK ABOUT THE POLICIES OF EACH REGISTRY, NOT THE CHARGES THAT PROVIDERS MAKE TO CUSTOMERS.

SO REGARDING THE REGISTRIES -- AFRINIC, FOR EXAMPLE -- THE PRICE OR THE CHARGE FOR THE ALLOCATIONS IS NOT INCLUDED IN THE POLICIES. THE POLICIES ARE JUST THE RULES TO GET THESE RESOURCES.

I THINK IT'S THE SAME CASE IN ALL THE REGISTRIES. THE PRICES FOR EACH RESOURCE, IT'S AN ADMINISTRATIVE MATTER AND IT'S NOT INVOLVED IN THE PROCESS -- IN THE POLICY DEVELOPMENT PROCESS.

SO AS SOMEBODY MENTIONED, THE ONLY ONE THAT'S CHARGING IS RIPE, AND THERE'S NO REASON. IT'S JUST ADMINISTRATIVE.

THE OTHER QUESTION WAS THE MARKET SIZE. I THINK IT'S PERHAPS FOR YOU, THE MARKET SIZE FOR.

>>GERARD ROSS: HI, MY NAME IS GERARD ROSS FROM APNIC.

I JUST WANTED TO CLARIFY ABOUT THE PRICING AT APNIC. YOU ARE HALF RIGHT TO SAY THE PRICING IS NOT BUILT INTO THE POLICY. THERE IS A SEPARATE FEE SCHEDULE FOR THE WAY THAT WE CHARGE. IT'S NOT RIGHT, HOWEVER, TO SAY THAT APNIC DOES NOT CHARGE FOR IPV6, BECAUSE WE DO.

THE IMPORTANT THING TO NOTE, THOUGH, IS WE DON'T SPECIFICALLY CHARGE FOR ADDRESSES. WE CHARGE MEMBERSHIP FEES, AND THE MEMBERSHIP TIER THAT PEOPLE ARE IN IS DETERMINED BY THE AMOUNT OF ADDRESSES THAT THEY HOLD.

IN APNIC, FOR EXAMPLE, AT THE NORMAL LEVEL, WHICH IS WHAT WE WOULD CALL A SMALL MEMBER, YOU LOOK AT THE AMOUNT OF IPV4 ADDRESS THAT THEY HAVE AND THE AMOUNT OF IPV6 THAT THEY HAVE. IF THEY BOTH HAVE THE MINIMUM -- IF THEY HAVE THE MINIMUM ALLOCATION OF BOTH, THEN THERE'S A CHARGE AT THAT MEMBERSHIP LEVEL.

SO IF AN ORGANIZATION ALREADY HAS THE MINIMUM HOLDING OF IPV4, AND THEN THEY GET THE MINIMUM OF IPV6, THERE WILL BE NO ADDITIONAL CHARGE FOR THAT. HOWEVER, IF IT WAS A NEW MEMBER WITH NO ADDRESSES AND THEY GOT IPV6 THEY WOULD BE CHARGED ACCORDING TO HOW MUCH THEY HAD.

>>JORDI PALET: YEAH, ACTUALLY TO SAY IT CORRECTLY, IT'S ABOUT THE SAME IN ALL THE REGIONS. THE POINT IS IF YOU ARE AN EXISTING IPV4 CUSTOMER, AND YOU ASK FOR IPV6, IN MOST OF THE REGIONS THE ADDITIONAL COST FOR THOSE IPV6 ADDRESSES IS ACTUALLY WAIVED BY DECISION OF THE BOARD. TYPICALLY, IT'S THE DECISION OF THE BOARD IN MANY OF THE REGIONS.

SO IT'S ACTUALLY INCORRECT TO SAY IT'S NOT CHARGED. IT'S JUST A QUESTION OF IT'S NOT CHARGED BECAUSE IT'S ACTUALLY VOID BY THE BOARD DECISION UNTIL A CERTAIN PERIOD OF TIME THAT COULD CHANGE AT ANY MOMENT. BUT I THINK MOST OF THE REGISTRIES DECIDED THAT SOMETHING LIKE AT LEAST DURING ABOUT TWO YEARS, MORE OR LESS, BUT IF YOU ARE ALREADY AN EXISTING IPV4 CUSTOMER, LET'S SAY.

SO THAT'S THE POINT.

REGARDING THE OTHER QUESTION, I DIDN'T REALLY UNDERSTAND WHEN YOU SAY MARKET SIZE WHAT YOU ARE REFERRING. MAYBE YOU CAN CLARIFY THAT A LITTLE BIT TO PUT AN EXAMPLE, SOMETHING.

>>SEBASTIAN BELLAGAMBA: LET ME MAKE ANOTHER, REGARDING WHAT YOU SAID BEFORE.

YOU WERE REFERRING TO THE RIR MEMBERS AS CUSTOMERS. AND THAT'S NOT CORRECT. IT'S MEMBERS. BECAUSE BASICALLY RIRS ARE NOT IN THE BUSINESS OF SELLING IP ADDRESSES, BECAUSE ACTUALLY THEY ARE NOT FOR SALE. THAT'S WHY WE USE "ALLOCATE," BECAUSE THE IP ADDRESSES ARE ALLOCATED TO ISPS, NOT SOLD TO ISPS.

IF THEY DON'T NEED IT ANYMORE, THEY ARE BACK TO THE RIR POOL; OKAY?

ARE NOT SOLD, ARE NOT THE PROPERTY FROM THE ISP; OKAY?

>>PAULOS NYIRENDA: THE QUESTION WAS ON THE GLOBAL POLICY, I THINK ONE OF THE SLIDES SAID THAT THE ALLOCATION TO THE RIRS IS INDEPENDENT OF THE MARKET SIZE. I WANTED TO KNOW HOW THAT WAS ARRIVED AT AND WHAT'S THE JUSTIFICATION FOR IT.

>>SEBASTIAN BELLAGAMBA: LET'S CHECK THE....

YES. THE INITIAL ALLOCATION, IT'S A MATTER OF FAIRNESS.

THE INITIAL ALLOCATION FOR ALL FIVE RIRS WAS /12, INDEPENDENTLY OF THE MARKET SIZE IN EVERY REGION.

THAT'S EXACTLY FOR AFRINIC OR LACNIC.

WE ALL -- THE FIVE REGIONS GOT A /12 INDEPENDENTLY OF THE PROJECTIONS ON THE NEED FOR IPV6 ADDRESS SPACE IN THE FUTURE OR WHAT YOU HAVE DONE IN THE PAST; OKAY?

WE ALWAYS START OUT WITH THE SAME IP ADDRESS BLOCK. THAT'S WHAT I MEANT.

>>JORDI PALET: ANY ADDITIONAL QUESTIONS?

I GUESS IT'S TOO LATE TO START WITH THE LAST PART THAT WE HAD FOR THIS WORKSHOP. LET ME JUST INTRODUCE THE IDEA THAT WE HAD IN MIND, BUT UNFORTUNATELY WE DON'T REALLY HAVE TIME TO GO FOR THIS DEBATE, BUT MAYBE WE CAN JUST ANSWER A COUPLE OF QUESTIONS ON THAT.

THE IDEA WAS TO START A KIND OF DEBATE ON THE IDEA OF IPV6 AS AN INNOVATION OPPORTUNITY, ESPECIALLY FOR DEVELOPING COUNTRIES.

HOW I SEE THAT IS BASICALLY WHEN WE ARE DEPLOYING NEW NETWORKS, NEW INFRASTRUCTURES IN DEVELOPING COUNTRIES, IT'S EASY TO GET IPV6 DEPLOYED AT THE SAME TIME AS YOU ARE BUILDING UP NEW, TOTALLY NEW IPV4 INFRASTRUCTURE. SO INSTEAD OF GOING TO TWO PHASES, FIRST THE IPV4 AND THEN IPV6, JUST LET'S DO IT ALL TOGETHER. THAT'S THE FIRST POINT.

THE SECOND IS BASICALLY ONE OF THE DIFFICULTIES IN INCREASING THE, LET'S SAY, SPEED OF THE DEPLOYMENT OF IPV6 AND ACTUAL UTILIZATION OF IPV6 IS THE LACK OF APPLICATIONS AND SERVICES THAT REALLY TAKE ADVANTAGE OF THE NEW IPV6 FACILITIES.

THEY ARE COMING, BUT THEY ARE COMING SLOWLY. AND IT'S ACTUALLY THAT WE ALREADY EXPECTED, IN FACT, IF WE LOOK AT THE DEPLOYMENT OF IPV4, TO BE SUCCESSFUL, IT TOOK 30 YEARS. SO EXPECTING THAT IPV6 WILL BE READY IN JUST TEN YEARS, IT'S PROBABLY NOT THE CORRECT WAY TO SEE IT.

NEW SERVICES, NEW TECHNOLOGIES REALLY NEED TIME TO PICK UP.

SO THE POINT IS, ONE OF THE ADVANTAGES FOR DEVELOPING COUNTRIES OR HOW THEY CAN TAKE ADVANTAGE SOMEHOW FROM IPV6 DEPLOYMENT IS, IT'S EASY -- ACTUALLY, IT'S MUCH EASIER AND LESS EXPENSIVE TO CREATE APPLICATIONS WHICH USE IPV6 INSTEAD OF TRYING TO DO SAME ADVANCE FUNCTIONALITY FROM IPV4. I DON'T SAY IT'S IMPOSSIBLE BUT REALLY IT'S MUCH MORE DIFFICULT IF YOU HAVE NET BOX AND UNIT TWO TO LOOK AT THE SCENARIOS AND THE NETWORKS AND THE SIZE OF THE SCENARIOS ON BOTH SIDES AND ALL THE POSSIBLE SITUATIONS YOU CAN FIND.

SO DEVELOPING SOFTWARE IS TYPICALLY SOMETHING WHICH THIS SIMPLICITY OF IPV6 BRING BACK TO THE NETWORK CAN BE DONE WITHOUT TOO MANY RESOURCES. SO IN DEVELOPING COUNTRIES WHERE THERE ARE PROBABLY NOT THAT MANY RESOURCES IN GENERAL AS IN MORE DEVELOPED COUNTRIES, LOOKING INTO NEW SERVICES, NEW APPLICATIONS, NEW SOFTWARE, DEVELOPING NEW SOFTWARE WHICH TAKE ADVANTAGE OF IPV6 CAN BRING THEM A WAY TO LOOK INTO INNOVATION AND PROBABLY BE ABLE ALSO TO EXPLORE.

SO I REALLY THINK IT'S IMPORTANT TO TRY TO CREATE SOME ADDITIONAL AWARENESS IN DEVELOPING COUNTRIES ABOUT IPV6 AND TRY TO MAKE SOFTWARE DEVELOPERS, ESPECIALLY, AWARE THAT IPV6 IS HERE AND THEY CAN CREATE NEW THINGS WHICH WILL NOT BE SO EASY WITH IPV4. THAT WAS THE BASIC POINT THAT WE WANTED TO WAKE UP IN THIS LAST PART OF THE SESSION. I'M NOT SURE IF SEBASTIAN OR CHRISTIAN WANT TO COMMENT ANYTHING ELSE. IF NOT, OPEN THE MIKE FOR COUPLE OF FINAL QUESTIONS AND THAT'S IT.

SO IF NO ADDITIONAL QUESTIONS....

OKAY. SO THANK YOU VERY MUCH TO EVERYBODY.

[ APPLAUSE ]