I have added a page: http://www.firstpr.com.au/ip/ivip/ivip6/lfe/
This considers extending the use of the proposed IPv6 Forwarding Label (the currently unused Flow Label) to forwarding inside edge networks. It also has a section listing the relatively modest upgrades required to the RIB and FIB of core routers: http://www.firstpr.com.au/ip/ivip/ivip6/lfe/#core-new-func I explore using the lower half of the 2^20 space for 2^19 values purely for prefixes in the core: 0 0001 to 7 FFFF Core - single global namespace. and the upper half: 8 0001 to F FFFF Edge - separate namespace for each network. (It would be possible to use all 20 bits in one way for the core and all 20 bits however each edge network likes, purely within that edge network. However I think it is more robust to keep the ranges of value separate.) There may be various uses for it in edge networks, but the most obvious one I can think of is getting Ivip6 traffic packets from the border routers of the recipient provider networks through that network to the ETRs which directly connect to the end-user networks. So the proposed Forwarding Label is used twice: 0xxx xxxx xxxx xxxx xxxx To get the packet from the ITR to the border router of the provider network where the ETR is. 1yyy yyyy yyyy yyyy yyyy To get the packet from that border router to the ETR. This use in the recipient provider network is not required by Ivip6 - but it might be handy in some situations. It avoids some problems with alternative approaches to getting the packet from the recipient border router to the end-user network: Tunnel by encapsulation to the ETR: Packet overhead and PMTUD problems. No ETR - make the provider's internal routing system handle the prefixes of all the end-user networks: Unwieldy - and presents scaling problems for the internal routing system. Also, it is less complex for the FIB of each internal router to forward packets using the proposed Forwarding Label than to do the usual classification of the packet by analysing up to 48 bits of the destination address. Up to 524,287 provider networks: each with up to 524,287 ETRs, (274 billion possible ETRs): each able to handle many end-user networks. That should be sufficient! In the core, it is OK to have non-upgraded routers - but there can't be any ITRs or ETRs behind them. In the edge networks, it is OK to have some non-upgraded routers - but routes to ETRs (or any outer route which is used by the internal Label Forwarding system) shouldn't go through them. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
