<div dir="ltr">Hi guys,<div><br></div><div style>I have been following everything I can find for a while about IPv6 deployments trying to learn all I can from them, And I have a question for you. Why do network operators often seem to assign global addresses to interfaces instead of just to routers? Most of the Tier 1/2 network router addresses on traceroutes seem to be global per-interface addresses.<br>
</div><div style><br></div><div style>My 'proposed' (?) example 'core' router: Assigned 2001:db8::A1:34:56:42/128 to loopback. All interfaces requiring some kind of static configuration assigned address fe80::A1:34:56:42/64 to point static routes etc at*^, and other routers addressed in config as fe80::<router>%interface (i believe that syntax is required by the standards? for what that's worth).</div>
<div style><br></div><div style>*^ i assume static routes are few and far between, so perhaps fe80::2001:db8:cafe could also be 'next hop' for 2001:db8:cafe::/48 on each segment to make it easier to move between routers.</div>
<div style><br></div><div style>IPv6 routing protocols seem in some cases to exclusively use automatic link local addresses. Even for manual configuration, link locals deal with the ND exhaustion attack problem in the core quite nicely, while also simplifying address management.</div>
<div style><br></div><div style>Are there practical reasons for global addresses on router interfaces? My networks have them where there are devices connected, but I'm not sure if anything uses them for routing purposes. I have been ignoring the 'tunnel address' on my ltunnelbroker 6in4 tunnels and leaving my other layer 3 VPNs etc unnumbered without issue so far. When routing across ethernet networks I also use link-local addresses* to avoid another configuration to manage.</div>
<div style><br></div><div style>From when the discussion has come up it has been reported that assigning a global address to the loopback interface and having ICMP generation/management use that is widely supported by cisco/juniper/etc gear with 1/2 lines and works out of the box on linux? Distributing these loopback addresses in your IGP the same way you distribute the interface addresses now would seem to reduce IGP table sizes while still functioning the same. In theory with only a single address per device the backbone could use a single aggregate for addressing the core with scalable logical address assignment**.</div>
<div><br clear="all"><div>- Mike</div><div><div><br></div><div>[Sorry it turned into a long post, but i'm hoping to spark a discussion on the pros/cons of different approaches - <span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica">"96 more bits, no magic... but, way simpler</span>?"]</div>
<div><br></div></div><div style>*I use fe80::1 as the 'default gateway' in static server configs. fe80:: as (deprecated?) 'link-local any-router' address seemed ideal until I quickly found 'any' includes devices with no 'off' switch, hence the :1.</div>
<div style><br></div><div style>** Example: 2001:db8::XX:YY:ZZ:ID/128 XX=Region,YY=PoP, ZZ=Suite/Rack?, ID=Router, each can be 0-FFFF. This 'large network' example has a single aggregate /64*** you can either route without ND worries or drop at the edge as desired.</div>
<div style><br></div><div style>*** routing performance of longer than /64 shouldn't matter for packets going to low traffic interfaces? especially if filtered from inbound external traffic</div>
</div></div>