On 29/07/2008, at 11:19 AM, Basavaraj Patil wrote:
Hi Ric,
On 7/29/08 4:43 AM, "ext Richard Pruss" <[EMAIL PROTECTED]> wrote:
I made pretty much the same observation on Pana for DSL yesterday.
Nope. There is no modification to DHCP at all when PANA is used. No
new DHCP
options, messages, changes to the state machines, etc.
And you propose a whole new protocol that is not supported on all the
network devices in question.
I hope you are not implying that with DHCP-auth there is no
implication or
impact to hosts or network devices in question. What you are
proposing is
essentially transforming DHCP into an entirely new protocol. You are
just
riding on the DHCP coattails and expect EAP to get a free ride...
But I
don't believe it is that simple.
Actually it is. We have DHCP implementations integrated to subscriber
control and RADIUS and we have EAP.
The gap to implementation of this is by design very small.
- Ric
-Raj
- Ric
Alper
- Ric
Alper
Alper
-----Original Message-----
From: Alper Yegin [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 26, 2008 2:28 AM
To: 'Richard Pruss'
Cc: '[email protected]'; '[EMAIL PROTECTED]'
Subject: RE: [Int-area] dhcp-auth
I don't appreciate your comments. Let's stay on the technical
course.
Let's start just looking at the issues about Figure 3...
- What is the DHCP-wise functionality of the NAS? Text claims
it is
a "DHCP
relay" but I see it terminating some of the DHCP messages and
also
generating some other messages. This is not compliant with
DHCP.
As we explained to you many times most vendors BRAS's act as a
DHCP
proxy and terminate all messages and look like a server to the
client.
That's not accurate according to Figure 3. I see "some" DHCP
messages
terminating on the NAS (e.g., DHCPEAP*) and "others" going
through
(e.g.,
DHCPDISCOVER) within the same DHCP flow.
I don't think it is as simple as your two-sentence explanation
anyways. As
requested earlier, IETF needs to see a document where this DHCP
proxy
model is defined. I'm aware of one DHCP proxy model and it is
nothing like
what your document is suggesting.
Can you please send us a document that describes the DHCP proxy
model?
IETF needs to buy in the DHCP proxy model before any other
proposal
built
on top of that gets accepted.
- How does the NAS handle EAP retransmissions? It needs to send
unsolicited
DHCP messages to the DHCP client. This is not compliant with
DHCP.
Actually that issue is open and we can discuss what a compliant
implementation would mean in terms of retransmission timers so
that
right thing always happens at the right layer.
OK, please explain.
- I see NAS inserting additional DHCP option (EAP Success) on
DHCPOFFER as
it forwards that message from DHCP server to DHCP client. This
again
breaks
DHCP.
As we explained to you many times most vendors BRAS's act as a
DHCP
proxy and terminate all messages and look like a server to the
client.
Again, NAS does not really terminate "all" messages (see above).
And this
"box in the middle" inserting DHCP options towards the DHCP
client
breaks
DHCP.
Lets take this to the dhcwg list as that is where the review
happens
next week.
Really? What happened to the escalation of this discussion to
int-
area and
the outcome of the poll from last IETF? I hope Jari can clarify
this.
Alper
- Ric
Alper
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
dhcwg mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
