Mark,As Mikael said, ICMPv6 messages would not be sourced from link-local addresses if the destination IP was a global unicast address, but the question of what address they do use would be up to implementation. Agreed there is a need for device management such as DSLForum TR-69 and as you point out, we need an address for sourcing DNS, NTP, etc. Options that have been discussed with some of my peers include: - Using a small network from the delegated prefix for purposes of network management (the loopback that Mikael suggest). For example:
Delegated 2001:db8::/56Device uses 2001:db8::/64 for "management functions"- with 2001:db8::0 as the interface/loopback IP address
2001:db8:0:1::/64 for LAN interfaceConcerns with this approach is that you depend on the CPE to decide what prefix to use - and then there is the "dedication" of a whole ::/ 64 to the job (if that is a concern to others). For ICMP it should be up to the CPE to decide what address to respond from, but for ISP management and TR-69, it would be nice to know in advance what IP is "listening" (though TR-69 would not require this as it has the concept of device registration).
- Approach 2, use the LAN IPv6 address for management. The issue here is interface state. Ie, if WAN interface is up, but LAN interface is down then this is a bad situation.
Unfortunately devices like edge routers, BRAS, BNG and CMTS do have finite resources. While it may seem inconsequential to have two prefixes assigned to a customer for anti-spoofing entries, routes, accounting and classification - it really could add up! Today, most broadband customers are represented by a single /32. During IPv6- transition, we need to add another prefix so now we have two per subscriber. Do we want to go to three (ie, a IPv4 /32, the "WAN" ::/ 128 and a ::/56)? Note that link-local does not need to be used for anti-spoofing, accounting and classification as no customer-sourced traffic (except DHCP and BNG-initiated ICMP) would use this src address, nor would it go anywhere.
I understand there has been operational experience with such a model per RFC 4241 but I have not had personal experience with it in IPv6, or the equivalent of the CPE WAN being IP(v4) unnumbered for broadband subscribers. In my experience the use of ICMP ping is not a reliable way of doing first-mile assurance and hence it the ATM world we used ATM OAM F4/F5, in Ethernet we use IEEE 802.3ah/802.1ag. The operational issue with an IP-level analysis is that there is a lot of non-IP equipment between subscriber IP interface and ISP IP interface.
By the way, I think the option should be there but I'd like to work through the alternative to understand the issues.
-d On 03/01/2008, at 5:51 AM, Mikael Abrahamsson wrote:
On Thu, 3 Jan 2008, Mark Smith wrote:It's also common for CPE to run a caching DNS servers and NTPpeers these days, which the downstream devices can use, so they'd breaktoo.No, the CPE would use a loopback address for sourcing packets destined to the outside (or it's LAN adress).I understand the motive for the suggestion, however I don't really seehow it couldn't be more trouble than it's worth. A ULA prefix on that upstream link would address some of the issues, but not all of them. I think to provide global Internet access you really need to ensure a fully globally addressed path to and from the Internet.So you think that "ip unnumbered loopback0" in IPv4 is really weird to have on WAN interface? It's basically the same thing.-- Mikael Abrahamsson email: swmike@swm.pp.se