Hi Peter,
> So as stated earlier I think one of the advantages the draft is
> providing is to allow authentication before address assignment.
>
> As I understand it with pana we have to have address assignment
> before the authentication, and as such if the end-device is
> getting ip-address from dhcp, the end-device will have to get
> a ip-address from dhcp, then do authentication, and possible
> be rejected or possible have the dhcp process boot-strapped
> to pana, so when the authentication is successful the dhcp
> process can request a new public address.
No.
It's true that the client has to configure "a" IP address before running
PANA. That can be a (IPv4 or IPv6) link-local address, or a short-lease DHCP
address.
[Btw, DHCP-proponents claimed the client using an IP address prior
to
authentication is such a big problem, yet they did not answer how
it'd
work with DHCPv6 where the client is already autoconfigured with
IPv6
link-local address]
And once the access authentication is successful, now the "session IP
address" can be assigned via DHCP.
> I do not think anyone is argueing that the pana solution is not
> workable, what is said is it will require more time and more
> resources on the NAS to handle several dhcp address allocations
> per end-device.
We debated that and it is not clear why that should be the case. First of
all, the IP address used with PANA does not have to be assigned by DHCP.
> Knowing how carriers in broadband networks constantly are trying
> to get as many subscriber authentications in as little time as
> possible, I think options that will streamline the authentication
> process have to be looked at.
I don't see a show stopper in PANA towards that goal.
Alper
>
> Peter
>
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED]
> > Sent: 5. december 2007 10:54
> > To: Richard Pruss
> > Cc: [EMAIL PROTECTED]; 'Sam Hartman'
> > Subject: Re: [Int-area] EAP and DHCP end-points
> >
> > Section 5.5 of DSL TR-101 says:
> >
> > R-181 The Broadband Network Gateway MUST be able to function as a DHCP
> > Relay Agent as described in RFC 951 "BOOTP", RFC 2131 "DHCP" and RFC
> > 3046 "DHCP Relay Agent Information Option" on selected untrusted
> > interfaces.
> >
> > R-182 The Broadband Network Gateway MUST be able to function as a DHCP
> > relay agent on selected trusted interfaces, when an access node acts
> > as a Layer 2 DHCP relay agent as specified in Appendix B -- Layer 2
> > DHCP Relay Agent.
> >
> > Given that BNG is equivalent to NAS and your answer is accurate, how
> > does your answer satisfy the TR-101 requirements?
> >
> > Yoshihiro Ohba
> >
> >
> >
> > On Wed, Dec 05, 2007 at 10:10:17AM -0800, Richard Pruss wrote:
> > > The answer you got was accurate but possibly not clear.
> > >
> > > The BRAS (NAS on the diagram) is a DHCP server to the client.
> > >
> > > We call a device acting like a DHCP server to the HGW and
> > client to the
> > > central DHCP Server a proxy and so does Juniper.
> > >
> > > In retrospect I made the mistake of calling it a relay in
> > the document
> > > because I was trying to support Richard Johnsons draft
> > > which documents the existence of these implementations and
> > tries to move
> > > them towards being relays by documenting how to
> > > override the server-id attribute.
> > >
> > >
> > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-d
> > hc-server-override-05.txt
> > >
> > > - Ric
> > >
> > >
> > > Alper Yegin wrote, around 4/12/07 10:59 PM:
> > > >Today Sam asked a question about the EAP end-points with respect to
> > > >dhcp-auth proposal.
> > > >
> > > >The answers we got were either not clear or not accurate.
> > > >
> > > >It is not true that EAP authenticator is always on the
> > DHCP server. In
> > > >Figure 5 of their I-D, EAP authenticator and DHCP relay
> > are co-located in
> > > >NAS:
> > > >
> > > >
> > > > (HGW) (NAS) (AAA)
> > (DHCP)
> > > > DHCP Client AAA Client RADIUS Server
> > DHCP Server
> > > > AAA Client
> > > >
> > > > DHCPDISCOVER ------->
> > > > (w/DHCP-auth-proto EAP)
> > > >
> > > > <------- DHCPEAP
> > > > (w/EAP Message)
> > > >
> > > > DHCPEAP ------->
> > > > (w/EAP Message)
> > > >
> > > > RADIUS Access-Request ------->
> > > > (w/EAP Message)
> > > >
> > > > <-------- RADIUS
> > > > Access-Accept (w/EAP Message)
> > > > (Access-Reject (w/EAP Message)
> > > > if unsuccessful)
> > > >
> > > > (DHCP messages continue normally from
> > > > this point forward if successful)
> > > > DHCPDISCOVER
> > ------------------------------>
> > > > (w/RADIUS attributes suboption)
> > > >
> > > >
> > <----------------------------- DHCPOFFER
> > > >
> > > > <------- DHCPOFFER (w/EAP Success Message)
> > > > (w/yiaddr)
> > > >
> > > > DHCPREQUEST ------->
> > > >
> > > > <------- DHCPACK
> > > >
> > > > Figure 5: Message Flow with new message and a DHCP relay
> > > >
> > > >
> > > >As for EAP peer and DHCP client, we never got a clear
> > acknowledgement that
> > > >it may be on a device sitting behind the CPE (HGW) at
> > home, like a PC. It
> > > >has to be so because:
> > > >- There are clear DSLF requirements for that [e.g.,
> > IPAuth-9 Should be
> > > >simple to implement on client (PC or CPE)],
> > > >- Replacing PPPoE means doing that on the home PCs as well, and
> > > >- The I-D clearly states "The DHCP Client resides either
> > on a home network
> > > >device or the HGW,..."
> > > >
> > > >
> > > >Alper
> > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >Int-area mailing list
> > > >[email protected]
> > > >https://www1.ietf.org/mailman/listinfo/int-area
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > Int-area mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/int-area
> > >
> >
> >
> > _______________________________________________
> > Int-area mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/int-area
> >
>
>
>
>
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
