IPv6 PPP/RADIUS and PD on Redback SEOS 6.4.1

[Arjan Van Der Oest]

On 28Feb, 2011, at 22:56 , David Freedman wrote:
> You are correct, the traffic should be wrapped in IPv6CP which should be
> carried over the PPP, not sure what kind of service you have from KPN but
> I can't imagine there is one where they would interfere with this?

They deliver a layer-2 ether connection between us and the customer. However, it's not transparent all the way, they do some 'intelligent' stuff (protecting my bras' MAC, it can not be poisoned by the customer, DHCP option 82 insertion (no, they do not relay, they only insert option-82 with a customer-tag to identify the circuit) etc.

When ordering a customer vlan you'll have to choose wether this is going to be a DHCP based of PPPoE based vlan and they will insert this customer's traffic in reserved vlans on my side (when ordering, you'll have to indicate the type of connections it's going to serve).

Since their DSLAMs doesn't seem to support DHCPv6 snooping (earliest end 2011 according to my source, plenty of time KPN....) they are not able to offer me IPv6 on these type of connections, so I'm forced to work with PPPoE. They will also insert a customer-tag in the PADI such that the circuit can be identified regardless of the username/password being used by the user.

> I can see the packet is sourced from your IID correctly

IID?

> , can you get a PPP
> debug (I.e debug PPP packet) from the CPE?

Sure:

035763: .Feb 28 22:11:27.185: Vi1 PPP: I pkt type 0x8021, datagramsize 12 link[ip]
035764: .Feb 28 22:11:27.185: Vi1 IPCP: I CONFREQ [REQsent] id 126 len 10
035765: .Feb 28 22:11:27.185: Vi1 IPCP:    Address 94.247.1.1 (0x03065EF70101)
035767: .Feb 28 22:11:27.189: Vi1 PPP: I pkt type 0x8057, datagramsize 16 link[ipv6]
035768: .Feb 28 22:11:27.189: Vi1 PPP: I pkt type 0x8057, datagramsize 16 link[ipv6]
035768: .Feb 28 22:11:27.189: Vi1 IPCP: O CONFACK [REQsent] id 126 len 10
035769: .Feb 28 22:11:27.189: Vi1 IPCP:    Address 94.247.1.1 (0x03065EF70101)
035770: .Feb 28 22:11:27.189: Vi1 IPCP: I CONFNAK [ACKsent] id 1 len 10
035771: .Feb 28 22:11:27.189: Vi1 IPCP:    Address 94.247.1.8 (0x03065EF70108)
035772: .Feb 28 22:11:27.189: Vi1 IPCP: O CONFREQ [ACKsent] id 2 len 10
035773: .Feb 28 22:11:27.189: Vi1 IPCP:    Address 94.247.1.8 (0x03065EF70108)
035774: .Feb 28 22:11:27.189: Vi1 IPV6CP: I CONFREQ [REQsent] id 116 len 14
035775: .Feb 28 22:11:27.189: Vi1 IPV6CP:    Interface-Id 0230:88FF:FE16:EAFF (0x010A023088FFFE16EAFF)
035776: .Feb 28 22:11:27.189: Vi1 IPV6CP: O CONFACK [REQsent] id 116 len 14
035777: .Feb 28 22:11:27.189: Vi1 IPV6CP:    Interface-Id 0230:88FF:FE16:EAFF (0x010A023088FFFE16EAFF)
035778: .Feb 28 22:11:27.193: Vi1 IPV6CP: I CONFACK [ACKsent] id 1 len 14
035779: .Feb 28 22:11:27.193: Vi1 IPV6CP:    Interface-Id 021D:A2FF:FE27:27A0 (0x010A021DA2FFFE2727A0)
035780: .Feb 28 22:11:27.213: Vi1 PPP: I pkt type 0x8021, datagramsize 12 link[ip]
035781: .Feb 28 22:11:27.213: Vi1 IPCP: I CONFACK [ACKsent] id 2 len 10
035782: .Feb 28 22:11:27.213: Vi1 IPCP:    Address 94.247.1.8 (0x03065EF70108)
035783: .Feb 28 22:11:28.161: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
035784: .Feb 28 22:11:28.165: Vi1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x4270B27C
035785: .Feb 28 22:11:28.185: Vi1 LCP-FS: I ECHOREP [Open] id 1 len 12 magic 0x7E3D3E0F
035786: .Feb 28 22:11:28.185: Vi1 LCP-FS: Received id 1, sent id 1, line up

-- 
Met vriendelijke groet,

Arjan van der Oest
Senior Network & Systems Engineer / Security Officer

Voiceworks BV - Editiestraat 29 - 1321 NG Almere
Mobile : (+31) (0)36 7600 197
Voiceworks winnaar Gouden FD Gazelle Award 2010 http://bit.ly/eksf8V