> -----Original Message----- > From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] > Sent: 11 December 2007 21:12 > To: Wojciech Dec (wdec) > Cc: Yoshihiro Ohba; Mark Townsley (townsley); Jari Arkko; > [email protected] > Subject: Re: [Pana] Re: DSLF Requirement analysis > > On Tue, Dec 11, 2007 at 08:46:14PM +0100, Wojciech Dec (wdec) wrote: > (snip) > > > > > > I agree that some mechanism to carry circuit-id in PANA message > > > would be needed when DHCP is not used for obtaining a pre-PANA > > > address, in order to avoid any change to existing RADIUS > > > implementations. We (PANA WG) can certainly work on a > mechanism to > > > carry a circuite-id in PANA-Client-Initiation > > > (PCI) message if needed. That's not a big deal than adding a > > > mechanism to carry EAP over DHCP in terms of IETF > specification work. > > > > > > On the other hand, there are also other PANA use cases in > which DHCP > > > is used for obtaining a pre-PANA address. In such cases, I don't > > > think any change to existing RADIUS implementations is > needed. So > > > overall, I think the current assessment is still valid. > > > > The issue is that an operator will deploy one mode of PANA or the > > other, not both. The assement should indicate which one is > assumed for > > the answers. > > I think at this moment it is hard for PANA WG to > determine/suggest which use case should be used for DSL (more > requirements are expected to recommend one). But we can > certainly include detailed assessment (like above) if that > helps DLSF to understand the assesment better.
This would be certainly helpful. > > > The other issue, as in my previous mails, is that if this extra > > coupling of DHCP-PANA-AAA state is assumed then it complicates BRAS > > implementations and more significantly operations. > > As I expressed previously, I don't agree with this issue > since there is no written requirement on BRAS complexity. > The thing is that the PANA usage models require not only more complex BRAS mechanisms (at least), but also affect the SP's operations. The assessment carries no mention of this. > > > > > > More information is available on the short lease with Windoes DHCP > > > server: > > > > > > http://support.microsoft.com/kb/261964 > > > > > > "After a Dynamic Host Configuration Protocol (DHCP) client lease > > > expires, it is not immediately scavenged from the > database." This > > > means Windows DHCP server is slow to update the database > (and hence > > > short lease is not recommended). On the other hand, I could not > > > interprete the text to indicate all DHCP servers on any > OS have the > > > same issue and/or Windows DHCP clients do not work with > short lease. > > > > Woj> Let's say that this is a grey area. My previous feedback from > > operators has highlighted that this is an issue. That said > unless the > > PANA WG can claim with 100% accuracy that it's not an issue, the > > assement is not accurate. > > I don't really see an issue unless operators are clear about > what the exact issue on existing DHCP client with short lease. > >From a vendor perspective, we tried it and we're not going there again following customer feedback. > > > > > > I don't really understand why configuraing IPv6 > link-local address > > > before authentication will satisfy DSLF requirements while > > > configuraing IPv4 address before authentication won't. > > > Can you please explain? > > > > Woj> I'm specifically not addressing IPv6, because how IPv6 should > > actually be deployed in broadband is a grey area for me. I > can count > > on one hand the # of operators I know who have done so, and amongst > > these there are differences. > > Given that IPv6 needs to be considered according to > IPAuth-11, I don't see an issue on assigning an IP address > before authentication. For the same reason, assigning an IP > address before authentication should not be an issue even for > DHCP authentication for IPv6. > This is a bit of a conundrum composed of; - Widely deployed IPv4 security mechanisms rely on DHCP assignement of the address before any L2 communication is enabled. This eliminates the local-link address PANA usage model and forces the pre-PANA address pools (short leases and all) - Short leases force the use of dedicated pools, and their management, besides extra operational and device complexity (to say the least) None of these facts seem to have been considered in the assessment. > Yoshihiro Ohba > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
