User Story

• As a Communication Service Provider (CSP) operating PortaSwitch/PortaBilling, I want to accept, authenticate, and bill IPv6-only and dual-stack subscribers the same way I already do for IPv4-only ones, so that I can keep growing my business as networks migrate to IPv6, without deploying extra translation infrastructure.
• As a subscriber, I want my voice calls, internet, and messaging services to keep working whether my device uses IPv4, IPv6, or both, so that I don't need to change any settings or contact support, and the transition never causes a gap in the services I pay for.

Background: The global pool of IPv4 internet addresses is exhausted, and network operators worldwide are actively migrating to IPv6. New mobile networks, IoT platforms, and enterprise infrastructure are increasingly being built IPv6-only; most existing networks are adding IPv6 alongside IPv4. This transition happens at the infrastructure level — subscribers don't choose it, and CSPs cannot opt out of it. CSPs whose platforms cannot natively handle IPv6 are already turning away customers whose infrastructure has moved ahead, and losing deals to competitors who support IPv6 natively. Subscribers on those platforms risk service gaps as their ISP or mobile operator completes the transition.

Example of use

• Voice + dual-stack:

  • A regional call center's cloud PBX extensions sit on an office network with both an IPv4 and a native IPv6 address active at once. Under normal conditions, each UA (softphone or desk phone) prefers IPv6 and registers over it, with calls placed entirely over IPv6. One afternoon, a routing issue degrades only the IPv6 path for twenty minutes during peak hours; each UA whose SIP stack supports address-family fallback re-registers over IPv4 at its next registration refresh (how quickly, and whether at all, is determined by the UA's own resolution and retry behavior — not by PortaSIP), and agents on those extensions keep taking new calls. Calls already in progress over the degraded IPv6 path are not expected to survive the switch. PortaSIP's role is to make the recovery possible: it accepts the IPv4 re-registration as the same account, replaces the binding, and delivers subsequent calls over the new family. If PortaSIP couldn't recognize both address families as the same account, even a perfectly behaving UA's fallback would show up as failed registrations — at the exact moment the network is already having a bad day.
• Internet/broadband + dual-stack:
  • A residential fiber ISP assigns every new subscriber both an IPv4 address and a native IPv6 prefix from day one — not as a special option, just the default. A subscriber's router keeps the IPv4 address active for older devices and apps while using the new IPv6 prefix for everything that supports it, simultaneously, on the same connection. Both address families need to be recognized as one subscriber generating one bill — not two. If the billing platform can't correlate a RADIUS exchange carrying both an IPv4 and an IPv6 attribute for the same session, the ISP risks one of three outcomes: the subscriber gets billed twice, support sees two confusing "active session" entries for one person, or usage on one address family is silently dropped and never billed at all.

Business model

Any

Technology

IPv6

Current Solution

• Current process (PortaSIP side — already implemented): PortaSIP's SIPProxy component inspects the Via and Route SIP headers to detect IPv6-originated or IPv6-destined calls arriving via DNS64/NAT64, and rewrites Record-Route and SDP c= attributes so the call completes between an IPv6 UA and an IPv4 SIP server. Internal PortaSIP component-to-component traffic (Dispatching SBC ↔ SIPProxy) stays IPv4. This has been in place since MR58
• Current process (PortaSIP side — workaround only, no native IPv6 support): PortaSIP has no native IPv6 support today. The only existing mechanism, in place since MR58, allows an IPv6 UA to reach PortaSIP indirectly through an operator-deployed DNS64/NAT64 layer: SIPProxy detects the translated address in the Via and Route headers and rewrites Record-Route and SDP c= accordingly, so the call can complete between the IPv6 UA and PortaSIP's IPv4 Service IP. PortaSIP itself listens on IPv4 only — it has no IPv6 Service IP, cannot accept SIP registrations directly from IPv6 UAs, and cannot signal or route calls over IPv6 without the translation layer in front of it.
• Current process (BillingEngine side — the gap): An administrator adds a NAS/BRAS as a Node with a single IP field, populated with an IPv4 address, which becomes the NAS-IP-Address RADIUS attribute used to match inbound RADIUS packets to the correct Node record. There is no documented way to register a Node by IPv6 address or to accept NAS-IPv6-Address as the matching key. Diameter Gy/Ro AVP processing likewise has no documented Framed-IPv6-Prefix/Delegated-IPv6-Prefix handling.
• Current process (PortaConfigurator side — the gap): since MR62 (FR-50) we have possibility to assign/modify IPv6 address(es) to/on network interface only (addresses on NICs, static routes, prefix lengths). However, the configuration generation layer — templates, macros, file paths, cluster resource naming, firewall protectors, and backend tooling — is not IPv6-ready.
• Pain points:
  • A BRAS/NAS whose RADIUS source address is IPv6-only cannot be matched to any Node, so all its RADIUS traffic is rejected (no partial degradation — total service outage for that NAS).
  • A dual-stack subscriber session reporting only Framed-IPv6-Prefix (no Framed-IP-Address) is authorized by the NAS locally (fail-open) but never billed, because PortaBilling's xDR has no IPv6 field to populate — usage is silently lost.
  • Every workaround today requires the CSP to operate NAT64/CGNAT purely to keep the RADIUS/Diameter conversation in IPv4, adding infrastructure cost and a second point of failure.

Stakeholders and their benefits

Who are the users / whom we bring value to?

Use Cases

Use case #1: PortaSIP native IPv6 signaling support

Roles: Administrator, End user (SIP account holder), NOC engineer (troubleshooting via Admin Web interface), PortaSIP

Preconditions: 

• PortaSIP cluster "SIP-Cluster-EU1" exists
• Administrator has an IPv6 Service IP 2001:db8:1::100 allocated for this cluster, with alias 2001:db8:1::101

Use scenario #1.1: Administrator configures an IPv6 Service IP for the PortaSIP cluster

• Administrator opens the configuration for cluster "SIP-Cluster-EU1" and enters Service IP 2001:db8:1::100 with alias 2001:db8:1::101
• Administrator saves the configuration
• PortaSIP accepts the IPv6 Service IP and alias and applies it to the cluster
• A test REGISTER sent to sip:[2001:db8:1::100] receives a 200 OK with Contact header correctly bracket-enclosed, e.g., <sip:[2001:db8:1::100]:5060>
• Note on scope coverage of SIP subscriptions and T.38 fax:
  • BLF, Presence, and MWI notifications are not listed as separate scenarios because they are implicitly covered by this use case. SIP SUBSCRIBE/NOTIFY/PUBLISH messages for these services flow through the same IPv6 VIPA established in Scenario #1.1 — the Subscription Manager is an internal processing node component reached via the dispatching node, never directly addressed by a UA. If the VIPA accepts IPv6 SIP traffic (as required by Scenario #1.1), BLF/Presence/MWI work over IPv6 without additional IPv6-specific changes.
  • T.38 fax is similarly covered: its signaling flows through the VIPA as a standard SIP INVITE with T.38 SDP, and the UDPTL transport is relayed by the same Call Controller that handles RTP for voice calls in Scenario #1.2. No T.38-specific IPv6 handling is required beyond what the Call Controller's IPv6 support already provides.

Use Scenario #1.2 Call between two native IPv6 UAs

Preconditions: 

• Customer "Nordic Voice" has extensions 210 ("Kristina Olsen") and 211 ("Peter Nilsson"), both registered to cluster "SIP-Cluster-EU1" from IPv6-only UAs, at addresses 2001:db8:20::15 and 2001:db8:20::16 respectively

Scenario:

• On 2026-04-05 at 11:00:00, extension 210 calls extension 211
• Extension 211 answers at 11:00:04
• Both parties speak for exactly 90 seconds
• Extension 210 hangs up at 11:01:34

Expected result:

• Call connects with two-way audio in both directions; no one-way-audio or media negotiation failure is observed
• xDR for this call shows: caller = extension 210, callee = extension 211, connect time = 11:00:04, disconnect time = 11:01:34, duration = 90 seconds
• Both legs' SIP identity fields in the xDR record the originating and terminating addresses as IPv6 (not translated to or mixed with IPv4)

Use Scenario #1.3 Call recording for a call carried over native IPv6

Preconditions:

• Customer "Nordic Voice" has the Call recording add-on product assigned to extension 215 (call center agent "Anna Berg")
• Extension 215 registers to cluster "SIP-Cluster-EU1" from an IPv6-only softphone
• On 2026-04-02 at 10:15:00, a customer calls extension 215; the call is answered and, per the assigned add-on product, automatically recorded
• The call runs for 4 minutes and 12 seconds and disconnects normally at 10:19:12
• Later, Anna's supervisor opens the Cloud PBX Self-Care Portal and plays back the recording for this call

Expected result:

• The call is recorded in full (4:12 duration), in the configured audio format, with no gap or corruption caused by the call being signaled over IPv6
• The recording is correctly associated with extension 215 and the 2026-04-02 10:15:00 call, and plays back normally from the Self-Care Portal
• No separate configuration step is required from the customer/end-user side; from their perspective, call recording behaves identically to an IPv4 call

Use Scenario #1.4 Voicemail for a call carried over native IPv6

Preconditions:

• Account anna.berg@nordicvoice.example, extension 215, has Voicemail enabled and an external notification email anna.berg@nordicvoice.example.mail
• Account anna.berg@nordicvoice.example, extension 215, has Voicemail enabled and an external notification email anna.berg@nordicvoice.example.mail, hosted on an external dual-stack mail server (its mail domain publishes MX records resolvable to both IPv4 and IPv6)
• Extension 215 is registered over IPv6 via cluster "SIP-Cluster-EU1"
• On 2026-04-03 at 09:00:00, a caller reaches extension 215 while Anna is unavailable; the call is routed to voicemail
• The caller leaves a 30-second message
• PortaSIP stores the recording and generates a notification email to anna.berg@nordicvoice.example.mail
• Anna later opens the Cloud PBX Self-Care Portal to listen to the message and reads its automatic transcription

Expected result:

• The voicemail message (30 seconds, correct audio format) is stored and visible in Anna's mailbox
• The notification email is delivered with a valid, readable "From" address — if no sender domain is configured, the fallback value derived from the SIP node's identifying address resolves to a well-formed email address (not a raw, unbracketed IPv6 literal, which is not valid in an email address)
• The notification email is successfully delivered from the Mail Proxy on the cluster's IPv6 VIPA to the external dual-stack mail server; no delivery failure occurs because the sending side's source address is IPv6, and the sent message passes standard acceptance checks at the receiving server (i.e., the IPv6 source does not trip malformed-HELO/EHLO or header-formatting issues the way a raw IPv6 literal in the From address would)
• Anna can play back the recording and read the transcription in the Self-Care Portal exactly as she could for a voicemail left via IPv4

Use Scenario #1.5 Call from a native IPv6 UA to a built-in IVR application

Preconditions: 

• Account lars.eriksson@nordicfiber.example (established as a broadband subscriber in Use Scenario #5.4) also has a Cloud PBX/SIP voice service bundled with a prepaid balance of $45.00, and is registered on an IPv6-only UA
• The Cloud PBX voice service on this account is configured as prepaid (debit) with an available balance of $45.00
• The CSP's built-in self-care balance-inquiry IVR is reachable by dialing *100 from a registered account

Scenario:

• On 2026-04-06 at 13:00:00, the account dials *100
• The IVR answers and plays: "For your account balance, press 1"
• The caller presses 1 via DTMF at 13:00:05

Expected result:

• The IVR correctly receives the DTMF digit 1 over the IPv6-carried RTP stream (not silently dropped or misread as a different digit)
• The IVR responds by speaking the account's actual current balance, "$45.00" — matching the precondition value exactly, confirming the DTMF input was correctly mapped to the balance-lookup action and not just acknowledged
• The call disconnects normally after the balance is read out; xDR shows the call as connected with the IVR application name logged

Use Scenario #1.6 SIP contact Static address accepts an IPv6 Host for incoming call delivery

Preconditions:

• Customer "Nordic Manufacturing" operates SIP trunking; account trunk-master@nordicmanufacturing.example has SIP contact "Deliver incoming calls to" set to Static address
• The customer's on-premises PBX has no IPv4 address at all — it is reachable only at IPv6 address 2001:db8:50::20, port 5060, Transport UDP
• DID 442071235000 is assigned to this account

Scenario:

• Administrator opens the account's Incoming calls configuration, SIP contact section, and enters Host 2001:db8:50::20, Port 5060, Transport UDP in the Static address fields
• Administrator saves the configuration
• On 2026-04-07 at 10:00:00, an external caller dials DID 442071235000

Expected result:

• PortaSIP routes the incoming call directly to [2001:db8:50::20]:5060 via UDP, correctly bracket-enclosing the IPv6 host in the outgoing INVITE's Request-URI and Via headers (e.g., INVITE sip:442071235000@[2001:db8:50::20]:5060)
• The customer's PBX answers the call normally; xDR shows the call connected, with the terminating address recorded as 2001:db8:50::20
• No configuration error is raised for entering a colon-containing IPv6 literal in the Host field, and the field is not silently truncated or misparsed the way a naive dotted-decimal validator would misparse it

Use Scenario #1.7 Forward to SIP URI resolves an IPv6-only forwarding destination

Preconditions:

• Extension 210 ("Kristina Olsen", customer "Nordic Voice", from Use Scenario #1.2) has Call forwarding mode set to Forward to SIP URI
• The SIP URI field is configured as 61234567@[2001:db8:60::5]
• A dedicated virtual connection for calls forwarded to SIP URI has been configured for this customer, per the standard prerequisite for this forwarding mode

Scenario:

• On 2026-04-08 at 09:30:00, a caller dials extension 210's DID; extension 210 does not answer
• PortaSIP applies the Forward to SIP URI rule and attempts to deliver the call to 61234567@[2001:db8:60::5]

Expected result:

• PortaSIP successfully routes the forwarded call to 2001:db8:60::5, and the call connects normally
• If this does not work today, the observable failure would be: the forward attempt fails silently or the caller is disconnected with no record of a forwarding attempt, and no xDR entry reflects the forward to the IPv6 target
• xDR for the original call shows a forwarding action to the IPv6 SIP URI target, consistent with how a forward to an IPv4 target is logged today 

Use Scenario #1.8 NOC engineer searches for a call by IPv6 address in the SIP Log Viewer (Admin Web interface)

Preconditions:

• The call from Scenario #1.2 (2026-04-05 11:00:00, extension 210 → extension 211, cluster "SIP-Cluster-EU1", Service IP 2001:db8:1::100) has completed
• NOC engineer opens the Admin Web interface, Toolbox > Log viewer (SIP session logs), and searches for sessions by node/Service IP, entering 2001:db8:1::100

Expected result:

• The search returns the 2026-04-05 11:00:00 call from extension 210 to extension 211, exactly as an equivalent search by an IPv4 Service IP would
• No separate search mode, prefix, or workaround is needed to search by an IPv6 address

Use Scenario #1.9 End user retrieves voicemail via IMAP, and an inbound email reaches the Media Server, over the cluster's IPv6 VIPA

Preconditions:

• The voicemail message from Scenario #1.4 (extension 215, account anna.berg@nordicvoice.example, 30-second message left at 09:00:00) is stored in the mailbox on cluster "SIP-Cluster-EU1"
• The mail domain nordicvoice.example publishes an MX record resolving to the cluster's IPv6 VIPA 2001:db8:1::100, where the Mail Proxy runs with SMTP transport on port 25; the mailbox host for client access resolves to the same VIPA for IMAP
• Anna's email client (standard IMAP-capable client) runs on a device with an IPv6-only connection at 2001:db8:20::30

Scenario:

• At 10:00:00, Anna's email client connects via IMAP to [2001:db8:1::100], authenticates as anna.berg@nordicvoice.example, and synchronizes the mailbox
• At 10:05:00, an external correspondent on a dual-stack mail server sends a regular email to anna.berg@nordicvoice.example; the sending server resolves the MX record and delivers the message to the Mail Proxy at [2001:db8:1::100]:25 over SMTP

Expected result:

• The IMAP session establishes over IPv6 and the 09:00:00 voicemail message (30 seconds, with audio attachment) downloads intact and plays correctly — identical to retrieval of the same mailbox over IPv4
• The inbound email is accepted by the Mail Proxy over IPv6 SMTP, stored, and visible in Anna's mailbox on the next IMAP synchronization
• No address-family-related failure occurs at connection, authentication, or transfer stage on either protocol, and no NAT64 or relay workaround is required in front of the VIPA
• Both interactions are logged/traceable the same way the equivalent IPv4 interactions are today
• If an Email callback trigger is configured for the domain, an email delivered over IPv6 SMTP triggers the callback exactly as one delivered over IPv4

Use case #2: PortaSIP native dual-stack support IPv4 and IPv6 (optional)

Roles: End user (SIP account holder), PortaSIP

Preconditions: 

• PortaSIP cluster "SIP-Cluster-EU1" is dual-stack: it has both an IPv4 Service IP and the IPv6 Service IP 2001:db8:1::100 configured (exact mechanism is up to SD phase)
• DNS for the SIP domain publishes both an A record (IPv4) and an AAAA record (IPv6) — this CSP has opted into voice dual-stack
• Account extension 220 ("Marcus Lindgren") uses a UA (office desk phone) with both IPv4 and IPv6 WAN connectivity

Use Scenario #2.1 Dual-stack SIP endpoint registration UA switches address family between registrations and PortaSIP maintains one correct binding

• On 2026-04-25 at 09:00:00, Marcus's UA resolves the SIP domain, receives both A and AAAA records, and registers over IPv6 to sip:[2001:db8:1::100]
• PortaSIP accepts the registration; at 09:05:00 Marcus places an outbound call that completes entirely over IPv6
• At 14:30:00, a brief IPv6 routing issue on Marcus's ISP causes his UA's next registration refresh to fall back to IPv4, registering to the same domain via the A record instead
• PortaSIP accepts the re-registration over IPv4 with no administrator action required
• At 14:35:00, Marcus places another outbound call, which completes entirely over IPv4
• On 2026-04-25 at 09:00:00, Marcus's UA resolves the SIP domain, receives both A and AAAA records, and registers over IPv6 to the cluster's published IPv6 address
• PortaSIP accepts the registration; at 09:05:00 Marcus places an outbound call that completes entirely over IPv6, disconnecting at 09:07:30
• At 09:15:00, Marcus's UA is manually reconfigured (or restarted after a firmware update) and, per its own SIP-stack behavior, re-registers using the domain's A record (IPv4) instead of the AAAA record it had used minutes earlier
• PortaSIP accepts the new registration over IPv4 with no administrator action required
• At 09:20:00, Marcus places another outbound call, which completes entirely over IPv4, disconnecting at 09:22:00

Expected result:

• Registration and calls succeed on both address families for the same account, with no reconfiguration needed when the UA switches
• xDRs for the 09:05:00 call (IPv6) and the 09:20:00 call (IPv4) both attribute correctly to extension 220
• No duplicate or orphaned registration records are created by the address-family switch
• Extension 220's registration status (Toolbox / SIP registration status) shows a single active registration at any given time, never two simultaneous ones for the same account
• After the 09:15:00 re-registration completes, extension 220's registration status (Toolbox / SIP registration status) shows exactly one active registration — the IPv4 binding; the earlier IPv6 binding is replaced, not retained alongside it
• Note for SD phase: some UAs re-register from the new family before the old binding expires, so a brief transient overlap of two contacts for the same account is legitimate; the binding-replacement rule (keyed by contact/instance identity vs. transport address) is to be defined during HLD/LLD

Use Scenario #2.2 Incoming call is delivered to the currently registered address family

• Continued from Scenario #2.1: extension 220's active registration is the IPv4 binding created at 09:15:00
• At 09:25:00, an external caller dials extension 220's DID
• PortaSIP delivers the incoming call to the UA's currently registered IPv4 contact

Expected result:

• The call is delivered over IPv4 (the family of the current binding), not attempted toward the expired IPv6 contact
• The call connects normally; xDR attributes the call to extension 220 with the terminating address recorded as the IPv4 contact
• Had the UA still been registered over IPv6, the same incoming call would have been delivered to the IPv6 contact — delivery always follows the current binding's address family

Use Scenario #2.3 Native IPv6 calls and legacy DNS64/NAT64 calls coexist on the same dual-stack SIP cluster

Preconditions:

• Cluster "SIP-Cluster-EU1" has IPv4 Service IP 198.51.100.100 and IPv6 Service IP 2001:db8:1::100 configured
• Customer "Nordic Voice" extensions 210 ("Kristina Olsen") and 211 ("Peter Nilsson") are registered natively over IPv6 (from Use Scenario #1.2), from UA addresses 2001:db8:20::15 and 2001:db8:20::16 respectively
• Extension 216 ("Jonas Vik") uses a mobile softphone on an IPv6-only mobile network with operator-side DNS64/NAT64 (NAT64 prefix 64:ff9b::/96); the softphone reaches the cluster's IPv4 Service IP via the synthetic address 64:ff9b::c633:6464 (= 198.51.100.100), i.e., the pre-existing MR58 path
• Extension 212 ("Eva Holm") is registered over IPv4 from a desk phone at 203.0.113.30

Scenario:

• On 2026-04-09 at 11:00:00, extension 210 calls extension 211 (native IPv6 → native IPv6); extension 211 answers at 11:00:05; the call lasts 120 seconds and ends at 11:02:05
• On 2026-04-09 at 11:01:00 — while the first call is still in progress — extension 216 calls extension 212 (DNS64/NAT64 path → IPv4); extension 212 answers at 11:01:06; the call lasts 60 seconds and ends at 11:02:06

Expected result:

• Both calls complete with two-way audio for their full durations; neither call degrades or disconnects the other
• For the 210 → 211 call, no synthetic (64:ff9b::/96-prefixed) address appears anywhere in the call's signaling, Record-Route, SDP c= values, or xDR; the xDR records the originating/terminating identities as 2001:db8:20::15 / 2001:db8:20::16
• For the 216 → 212 call, the legacy DNS64/NAT64 handling behaves exactly as documented today: PortaSIP presents its address toward the softphone in synthetic form (64:ff9b::c633:6464) and toward extension 212 as 198.51.100.100
• Two xDRs are produced: 210 → 211, connect 11:00:05, disconnect 11:02:05, duration = 120 seconds; 216 → 212, connect 11:01:06, disconnect 11:02:06, duration = 60 seconds — each attributed to the correct extensions, with no cross-contamination of addresses between the two calls
• In Toolbox > Log viewer, the 216 → 212 call is identifiable as NAT64-traversed (synthetic source visible), while the 210 → 211 call shows only native IPv6 addresses

Use Case #3: Wholesale/interconnect calls are matched and billed to the correct vendor when the vendor's traffic arrives from an IPv6 address

Roles: Billing Administrator (Vendor/Connection configuration), Vendor's remote gateway (interconnect partner)

Preconditions:

• Vendor "Baltic Transit" exists with two Connections: "baltic-transit-in" (type: From vendor) and "baltic-transit-out" (type: To vendor)
• Baltic Transit's SIP trunk now originates and terminates calls from/to IPv6 address 2001:db8:99::10 instead of its previous IPv4 address 198.51.100.10
• A second vendor, "Continental Carrier", has an unrelated Connection with remote IP 198.51.100.20

Use Scenario #3.1 Administrator updates the vendor Connection to match Baltic Transit's new IPv6 remote address

• Billing Administrator opens Connection "baltic-transit-in" and updates the remote IP field from 198.51.100.10 to 2001:db8:99::10
• Administrator saves the configuration
• At 2026-04-10 14:00:00, Baltic Transit sends an inbound call from 2001:db8:99::10 to DID 442071234567

Expected result:

• The call is matched to Connection "baltic-transit-in" and billed under vendor "Baltic Transit"'s tariff, exactly as it was when the remote IP was IPv4
• The call is not matched to vendor "Continental Carrier" or any other connection
• Vendor xDR shows the call attributed to "Baltic Transit", with the originating address recorded as 2001:db8:99::10

Use Scenario #3.2 Error alternative to #3.1: Connection is not updated, so an IPv6-originated call cannot be matched to any vendor

Preconditions:

• Connection "baltic-transit-in" still has the old IPv4 remote IP 198.51.100.10 configured; Baltic Transit's traffic now arrives only from 2001:db8:99::10
• At 2026-04-10 14:05:00, Baltic Transit sends an inbound call from 2001:db8:99::10
• PortaBilling cannot match the call's remote IP to any configured Connection

Expected result:

• The call is either rejected outright, or (if a fallback default connection/tech-prefix rule exists) misattributed to the wrong vendor — either outcome is a financial-accuracy defect
• No xDR correctly attributing the call to "Baltic Transit" is created
• This scenario is the direct interconnect-billing counterpart to the broadband/Node-matching failure already described in Use Scenario #5.9

Use Case #4 xDR Mediator imports xDRs identified by an IPv6 address

Roles: Billing Administrator (xDR import / Connection configuration), external gateway or carrier (record source)

Preconditions:

• Vendor "TATA Telecom" (an off-net termination carrier) sends batched call detail records to Nordic Fiber's PortaBilling for off-net calls it terminates on Nordic Fiber's behalf
• Vendor Connection "tata-cdr-import" (Service type: Voice calls, Direction: To vendor, Identify gateway by: IP) currently has Remote IP 203.0.113.40 (IPv4)
• TATA Telecom's switch has moved to IPv6-only management and now reports its records with NAS-IPv6-Address = 2001:db8:40::1

Use Scenario #4.1 Administrator updates the xDR-import Connection to identify the gateway by its new IPv6 address

• Billing Administrator opens Connection "tata-cdr-import" and updates Remote IP from 203.0.113.40 to 2001:db8:40::1
• Administrator saves
• On 2026-04-15, TATA Telecom uploads a batch CSV file containing 1,200 call records, each with NAS-IPv6-Address = 2001:db8:40::1
• The xDR Mediator's scheduled import run processes the file

Expected result:

• All 1,200 records are matched to Connection "tata-cdr-import" and imported as xDRs attributed to vendor "TATA Telecom"
• Each xDR is rated against the vendor tariff already configured for this Connection, exactly as it was when the Remote IP was IPv4
• No records are rejected or attributed to the wrong vendor

Use Scenario #4.2 Administrator configures automatic CDR retrieval from an IPv6-only FTP/SFTP source

Preconditions:

• TATA Telecom's file server, from which Nordic Fiber's xDR Mediator automatically downloads the daily CDR file, is now reachable only at IPv6 address 2001:db8:40::5
• Administrator updates the xDR import source configuration (CDRSourceFTPClient) with host 2001:db8:40::5

Scenario:

• The xDR Mediator's scheduled retrieval job runs at its next scheduled time, connects to 2001:db8:40::5 via SFTP, and downloads the day's CDR file

Expected result:

• The file is downloaded successfully and queued for extraction/import, exactly as it would be from an IPv4 host
• No manual workaround (e.g., a NAT64 gateway placed in front of TATA Telecom's server) is required purely to keep this retrieval working

Use Scenario #4.3 Error alternative to #4.1: Connection is not updated, so IPv6-sourced records cannot be attributed to any vendor

Preconditions:

• Connection "tata-cdr-import" still has the old IPv4 Remote IP 203.0.113.40; TATA Telecom's records now report NAS-IPv6-Address = 2001:db8:40::1
• On 2026-04-16, TATA Telecom uploads a new batch file with NAS-IPv6-Address = 2001:db8:40::1
• The xDR Mediator attempts to match each record's gateway to a Connection

Expected result:

• Records fail to match Connection "tata-cdr-import" (or any other Connection) and are rejected or left in an unprocessed/error state in the xDR collection
• None of that day's TATA Telecom traffic is billed to the customers who received those off-net calls, and none of the corresponding cost is recorded against vendor "TATA Telecom" — a direct revenue/cost-tracking gap, in the same family as Use Scenario #3.2
• The failure is visible to the Administrator via the xDR Mediation dashboard's collection status and the Log Viewer, consistent with how an IPv4 mismatch would already be surfaced today

Use Case #5 PortaBilling native IPv6 support

Roles: Administrator (Infrastructure > Nodes), BRAS/NAS equipment (RADIUS client), End user (broadband subscriber), PortaBilling (RADIUS server / rating engine)

Preconditions:

• Customer "Nordic Fiber", status open
• BRAS "MX960-Van-02" (Juniper MX960) is configured with IPv6 management/RADIUS-source address 2001:db8:5:100::1; it has no IPv4 address assigned on this interface
• Service "Residential Broadband 100/20" (Internet Access, upload+download megabytes rating base) exists and is assigned to product "Fiber Home 100"
• No Node currently exists in PortaBilling matching 2001:db8:5:100::1

Use Scenario #5.1 Administrator creates an IPv6-only Node

• On 2026-02-01 at 09:14:00, Administrator "Erik Lindqvist" opens Infrastructure > Billing data sources > Nodes > Add node
• Administrator enters Name "MX960-Van-02", Node ID "mx960-van-02.nordicfiber.example", leaves the existing IP (IPv4) field blank, enters 2001:db8:5:100::1 in the IPv6 field, sets Capable of IPv6 to Yes, Manufacturer Juniper, Type NAS
• Administrator clicks Save
• Administrator enables Communication with billing, selects Client protocol RADIUS, and sets RADIUS source IPv6 to 2001:db8:5:100::1
• Administrator clicks Save

Expected result:

• Node "MX960-Van-02" is created with IPv6 2001:db8:5:100::1, Capable of IPv6 = Yes, status active
• RADIUS Access-Request packets arriving with source address 2001:db8:5:100::1 and/or NAS-IPv6-Address = 2001:db8:5:100::1 are matched to Node "MX960-Van-02" — the system determines automatically, from the address family of the Node's configured RADIUS source address, that it must expect and emit NAS-IPv6-Address (rather than NAS-IP-Address) for this Node
• Audit log entry recorded: timestamp 2026-02-01 09:14:00, actor Erik Lindqvist, action "Node created", Node name MX960-Van-02, IPv6 2001:db8:5:100::1
• The system validates 2001:db8:5:100::1 as a well-formed IPv6 address (per NFR #2) and persists the Node record; no validation error is raised

Use Scenario #5.2 Alternative to #5.1: Administrator registers a dual-stack Node with both an IPv4 and an IPv6 address populated

Preconditions:

• BRAS "CX600-Van-01" (Huawei) has both IPv4 address 203.0.113.20 and IPv6 address 2001:db8:5:200::1 and may send RADIUS packets from either
• On 2026-02-03 at 11:00:00, Administrator adds Node "CX600-Van-01" with IP 203.0.113.20 and IPv6 2001:db8:5:200::1 both populated, and sets Capable of IPv6 to Yes
• Administrator clicks Save

Expected result:

• Node "CX600-Van-01" is created and matches inbound RADIUS traffic from either 203.0.113.20 (as NAS-IP-Address) or 2001:db8:5:200::1 (as NAS-IPv6-Address)
• Both the IP and IPv6 fields are visible and independently editable on the Node's General configuration panel
• No duplicate Node is created for the same physical NAS

Use Scenario #5.3 Error alternative to #5.1: Administrator enters a malformed IPv6 address

• On 2026-02-01 at 09:10:00, Administrator enters 2001:db8:5:100:1 (only 5 of the required 8 hextet groups, with no :: compression — invalid IPv6) in the IPv6 field on the Add node panel
• Administrator clicks Save
• System displays error: "Invalid IP address format. Enter a valid IPv4 or IPv6 address."
• Node is not created; Administrator remains on the Add node panel with entered values preserved

Expected result:

• No Node record is created
• Audit log records no "Node created" entry for this attempt

Use Scenario #5.4 Subscriber session authorized and accounted using Framed-IPv6-Prefix only

Preconditions:

• Node "MX960-Van-02" exists with IPv6 2001:db8:5:100::1 (from Use Scenario #5.1), Communication with billing enabled via RADIUS
• Account lars.eriksson@nordicfiber.example (User@domain role, consistent with how PortaBilling identifies broadband/data accounts today) subscribes to product 'Fiber Home 100' ($45.00/month, unlimited data)
• Account is configured for IPv6-only WAN addressing (no IPv4 assigned by the BRAS to this subscriber)

Scenario:

• On 2026-02-05 at 18:02:11, the subscriber's CPE sends a RADIUS Access-Request to Node "MX960-Van-02", which forwards it to PortaBilling with account lars.eriksson@nordicfiber.example and no Framed-IP-Address attribute
• PortaBilling authorizes the account and returns Access-Accept containing Framed-IPv6-Prefix = 2001:db8:5:1a2b::/64
• The BRAS establishes the session and begins sending Interim-Update accounting packets every 5 minutes reporting cumulative octets
• At 2026-02-05 19:02:11 (1 hour later), PortaBilling receives an Interim-Update reporting 2,048 MB transferred

Expected result:

• An active session for the account is visible under Toolbox > Active sessions, with subscriber_ip populated as 2001:db8:5:1a2b::/64
• No usage-based charge is generated (unlimited/fixed-fee product), but the session and its 2,048 MB usage are recorded and visible in Active sessions / xDR search
• At month end, the $45.00 recurring fee is invoiced normally, with no rejected or "unknown NAS" errors logged for this session

Use Scenario #5.5 NOC engineer searches for a session by IPv6 subscriber address in the BE Log Viewer or Active Sessions (Admin WI)

Preconditions:

• The broadband session from Use Scenario #5.4 (account lars.eriksson@nordicfiber.example, subscriber_ip = 2001:db8:5:1a2b::/64) is active
• NOC engineer opens the Admin Web interface, Toolbox > Active sessions, and searches by subscriber IP, entering 2001:db8:5:1a2b::/64

Expected result:

• The search returns the active session for account lars.eriksson@nordicfiber.example, exactly as an equivalent search by an IPv4 subscriber address would
• The same search works from Toolbox > Log viewer / xDR search for a completed (non-active) session

Use Scenario #5.6 Alternative to #5.4: Dual-stack subscriber session reports both Framed-IP-Address and Framed-IPv6-Prefix

Preconditions:

• Account lars.eriksson@nordicfiber.example is reconfigured for dual-stack WAN addressing
• On 2026-02-06 at 08:00:00, the CPE's Access-Request results in an Access-Accept containing both Framed-IP-Address = 203.0.113.55 and Framed-IPv6-Prefix = 2001:db8:5:1a2b::/64
• Accounting-Request messages report combined IPv4+IPv6 octet counts as a single session

Expected result:

• A single active session is recorded for account lars.eriksson@nordicfiber.example (not two separate sessions)
• subscriber_ip on the resulting xDR shows both addresses (e.g., 203.0.113.55 / 2001:db8:5:1a2b::/64) — both are recorded because they are active simultaneously within the same session
  • for the sequential handover case where one address replaces another mid-session, see Scenario #6.2
• Usage is counted once per byte transferred, regardless of which IP family carried it — no double-counting

Use Scenario #5.7 Alternative to #5.4: RADIUS-assigned static IPv6 address takes precedence over the router's local pool

Preconditions:

• Account maria.svensson@nordicfiber.example, product 'Fiber Home 100
• Account's Internet access service configuration specifies a static device address 2001:db8:abcd::1/64, netmask ffff:ffff:ffff:ffff::, and Routed Networks 2001:db8:abcd::/64 (Framed-IPv6-Route)
• Node "MX960-Van-02" additionally has a locally-configured IPv6 address pool 2001:db8:abcd:ffff::/64 for subscribers with no static assignment
• On 2026-02-08 at 07:30:00, account maria.svensson@nordicfiber.example requests internet access; Node "MX960-Van-02" sends a RADIUS Access-Request to PortaBilling
• PortaBilling authorizes internet usage and returns Access-Accept with Framed-IPv6-Prefix = 2001:db8:abcd::1/64 and Framed-IPv6-Route = 2001:db8:abcd::/64
• The BRAS assigns 2001:db8:abcd::1 to the subscriber's equipment, overriding its own local pool 2001:db8:abcd:ffff::/64

Expected result:

• Subscriber's equipment is assigned exactly 2001:db8:abcd::1, not an address from the BRAS's local pool
• Active session for maria.svensson@nordicfiber.example shows subscriber_ip = 2001:db8:abcd::1/64
• On every subsequent re-authentication for this account, the same static address 2001:db8:abcd::1 is returned (the assignment does not change session to session)

Use Scenario #5.8 Alternative to #5.4: No static IPv6 address configured; router assigns from its local dynamic pool

Preconditions:

• Account oskar.berg@nordicfiber.example, product 'Fiber Home 100
• Account's Internet access service configuration has no static IPv6 device address configured
• Node "MX960-Van-02" has a locally-configured IPv6 address pool 2001:db8:abcd:ffff::/64
• On 2026-02-09 at 09:00:00, account oskar.berg@nordicfiber.example requests internet access; the BRAS sends a RADIUS Access-Request to PortaBilling
• PortaBilling authorizes internet usage without returning a Framed-IPv6-Prefix (none is configured for this account)
• The BRAS assigns address 2001:db8:abcd:ffff::1 to the subscriber from its own local pool
• On 2026-02-10 at 09:05:00, the subscriber's session re-establishes and the BRAS assigns a different address, 2001:db8:abcd:ffff::2, from the same pool

Expected result:

• Both sessions (2026-02-09 and 2026-02-10) are authorized normally and visible in Active sessions, each showing the BRAS-assigned address reported via Accounting-Request (2001:db8:abcd:ffff::1 and 2001:db8:abcd:ffff::2 respectively)
• No authorization failure occurs due to the address changing between sessions
• Usage for both sessions is correctly attributed to account oskar.berg@nordicfiber.example, not lost or merged incorrectly

Use Scenario #5.9 Error alternative to #5.1: NAS reports from an IPv6 source address not registered to any Node

• On 2026-02-07 at 10:00:00, a RADIUS Access-Request arrives from source address 2001:db8:5:999::1, which does not match any Node's IP or additional IPv6 identifier
• PortaBilling rejects the request

Expected result:

• Access-Reject is returned to the sending NAS
• An entry is logged in Toolbox > Log viewer showing "Unknown NAS" with source address 2001:db8:5:999::1
• No session or xDR is created

Use Case #6 IoT/M2M data session charged over the Diameter Gy interface using an IPv6 mobile core

Roles: IoT SIM account, mobile-core P-GW (Diameter Gy client), PortaBilling (Gy server / rating engine)

Preconditions:

• Customer "ArcticIoT", account (Mobile/MSISDN role) 8801012345, product "IoT Data 50MB/day" ($0.005/MB pay-as-you-go), status open
• ArcticIoT's mobile core P-GW communicates with PortaBilling over Diameter Gy; the P-GW is IPv6-only and reports Framed-IPv6-Prefix instead of Framed-IP-Address in CCR messages. The P-GW has been registered in PortaBilling as a Node with its IPv6 transport address and Diameter Origin-Realm, following the same pattern as Use Scenario #5.1 (IPv6-only Node creation) — the configuration steps are identical in structure; only the Client protocol (Diameter instead of RADIUS) and the node identity fields differ.

Use Scenario #6.1 Data session authorized and charged via Gy using Framed-IPv6-Prefix

• On 2026-03-14 at 03:00:00, the P-GW sends a Gy CCR-Initial for account 8801012345, including AVP Framed-IPv6-Prefix = 2001:db8:9:aa::/64, requesting an initial quota
• PortaBilling authorizes the session and grants an initial quota of 10 MB
• Over the session, the P-GW sends CCR-Update requests reporting usage and requesting further quota; by 03:40:00 cumulative usage reaches 300 MB
• At 03:41:00, the P-GW sends CCR-Terminate reporting final usage of 312 MB

Expected result:

• Session for account 8801012345 shows total charged quantity 312 MB
• Charged amount: 312 × $0.005 = $1.56 USD
• xDR is created with subscriber_ip = 2001:db8:9:aa::/64, service "IoT Data 50MB/day", failed = 0
• Account 8801012345 balance is debited $1.56 USD (debit/prepaid) or the charge appears on the next invoice (credit/postpaid), per the account's configured billing model

Use Scenario #6.2 Alternative to #6.1: Mobile core hands the session over from IPv4 to IPv6 mid-session

Preconditions:

• CCR-Initial for account 8801012345 at 2026-03-15 06:00:00 reports Framed-IP-Address = 100.64.10.5 (CGNAT IPv4)
• At 06:00:00, session starts on IPv4 (Framed-IP-Address = 100.64.10.5), initial quota 10 MB granted
• At 06:15:00, a CCR-Update for the same Session-Id reports Framed-IPv6-Prefix = 2001:db8:9:bb::/64 as the network hands the device over to a native IPv6 bearer, with cumulative usage of 45 MB so far
• Session continues and terminates at 06:50:00 with final cumulative usage of 120 MB

Expected result:

• A single xDR is produced for Session-Id covering the full 06:00:00–06:50:00 session, not two separate xDRs
• Total charged quantity: 120 MB; charged amount: 120 × $0.005 = $0.60 USD
• xDR subscriber_ip field reflects the last-known address for the session (2001:db8:9:bb::/64); the earlier IPv4 address (100.64.10.5) is visible in the raw session event log accessible via Toolbox > Log viewer when searching by Session-Id, for troubleshooting purposes
• xDR subscriber_ip field reflects the last-known address for the session (2001:db8:9:bb::/64) — only the final address is recorded because IPv6 replaced IPv4 sequentially within the same Session-Id, not simultaneously; the earlier IPv4 address (100.64.10.5) is visible in the raw session event log in Toolbox > Log viewer when searching by Session-Id
  • contrast with Scenario #5.6 where both addresses are active at once and both are recorded

Use Scenario #6.3 Error alternative to #6.1: CCR arrives with Framed-IPv6-Prefix but no recognizable account identifier mapping

• On 2026-03-16 at 12:00:00, a CCR-Initial arrives with Framed-IPv6-Prefix = 2001:db8:9:cc::/64 but the Subscription-Id AVP does not match any existing account
• PortaBilling returns a Gy CCA with Result-Code = DIAMETER_USER_UNKNOWN

Expected result:

• No quota is granted; session is not authorized
• No xDR is created
• Rejection is visible in Toolbox > Log viewer with reason "User unknown" and the received Framed-IPv6-Prefix value for troubleshooting

Use Case #7 Quota-based bandwidth throttling and captive portal redirection on an IPv6 session

Roles: End user (broadband subscriber), Node "MX960-Van-02" (RADIUS client, CoA target), PortaBilling (RADIUS server / quota engine)

Preconditions:

• Customer "Nordic Fiber", account maria.svensson@nordicfiber.example (prepaid/debit), status open
• Product "Monthly Internet quota of 10 GB at 10 Mbps" — $100.00/month; once the 10 GB threshold is reached, standard overage pricing of $0.10/MB applies
• Account is on native IPv6 addressing per Use Scenario #5.7 (Framed-IPv6-Prefix = 2001:db8:abcd::1/64)
• Node "MX960-Van-02" supports RADIUS CoA and recognizes IPv6-Ingress-Policy-Name / IPv6-Egress-Policy-Name for applying a bandwidth-limiting filter
• The CSP's captive portal/hotline is reachable over IPv6 (has an AAAA record or a known IPv6 address); this is a CSP infrastructure requirement — PortaBilling's role is limited to sending the correctly-formed CoA-Request and enforcing the quota threshold

Use Scenario #7.1 IPv6 session reaches its quota threshold and is redirected to the captive portal at reduced speed

• On 2026-03-01 at 00:00:00, account maria.svensson@nordicfiber.example subscribes to "Monthly Internet quota of 10 GB at 10 Mbps" and makes a payment of $100.00
• The account's IPv6 session (subscriber_ip = 2001:db8:abcd::1/64) accumulates usage over the month; on 2026-03-18 at 14:22:00, cumulative usage reaches 10,240 MB (10 GB), crossing the threshold
• PortaBilling sends a RADIUS CoA-Request to Node "MX960-Van-02" containing IPv6-Ingress-Policy-Name = SPEED-LIMIT-64K and IPv6-Egress-Policy-Name = SPEED-LIMIT-64K
• The BRAS applies the named policy to the subscriber's IPv6 session and confirms with CoA-ACK
• The subscriber's next HTTP request over IPv6 is redirected to the hotline/captive portal

Expected result:

• Session subscriber_ip = 2001:db8:abcd::1/64 is throttled to 64 kbps effective 2026-03-18 14:22:00
• Account maria.svensson@nordicfiber.example usage-to-date shows exactly 10,240 MB, with no further usage-based charge yet applied (product is quota-based, not per-MB, until overage)
• Subscriber is redirected to the captive portal on the next request, over IPv6, without falling back to IPv4 to reach the portal

Use Scenario #7.2 Alternative to #7.1: Subscriber pays to restore full speed and continues on IPv6 at overage pricing

Preconditions: continued from Scenario #7.1

• On 2026-03-18 at 15:00:00, account maria.svensson@nordicfiber.example makes a payment of $100.00 via the captive portal to continue using the internet service at standard overage pricing of $0.10/MB
• PortaBilling sends a RADIUS CoA-Request removing the SPEED-LIMIT-64K policy from Node "MX960-Van-02"
• The BRAS confirms with CoA-ACK and restores the session to 10 Mbps on the same IPv6 address 2001:db8:abcd::1/64
• Over the remainder of March, the account uses an additional 500 MB

Expected result:

• Session speed is restored to 10 Mbps at 2026-03-18 15:00:00 without the subscriber's IPv6 address changing
• Additional usage of 500 MB is charged at $0.10/MB = $50.00, debited from the $100.00 payment, leaving a $50.00 balance
• On 2026-04-01, the monthly quota resets and the account resumes at full speed under the base $100.00 plan

Use Case #8 Self-care/Admin Web interface login sessions stay stable for users connecting over IPv6

Roles: End user (customer/account self-care, or Administrator on the Admin Web interface)

Preconditions:

• The CSP has Security.EnableSessionIdProtection enabled on the Configuration server
• Customer "Nordic Fiber", account lars.eriksson@nordicfiber.example, logs in to the Account self-care portal from an IPv6-only home connection with address 2001:db8:5:1a2b:aa11:bb22:cc33:dd44 (a privacy-extension address)

Use Scenario #8.1 User logs in and works a full session from a stable IPv6 address

• On 2026-04-11 at 08:00:00, the user logs in to the Account self-care portal from 2001:db8:5:1a2b:aa11:bb22:cc33:dd44
• The session is bound to this address
• The user views their bill and updates their contact email over the next 10 minutes, still from the same address

Expected result:

• All actions complete normally with no re-authentication prompt, since the bound address did not change during the session
• The session behaves identically to an equivalent IPv4 login

Use Scenario #8.2 Alternative to #8.1: User's IPv6 privacy address rotates mid-session

• On 2026-04-11 at 08:00:00, the user logs in from 2001:db8:5:1a2b:aa11:bb22:cc33:dd44; the session is bound to this address
• At 08:45:00, the user's operating system rotates its IPv6 privacy address (a routine, automatic OS behavior, not a network change) to 2001:db8:5:1a2b:ee55:ff66:1122:3344
• The user's next page request in the self-care portal now arrives from the new address

Expected result:

• The system detects the address change and shows the "authorize new IP address" notification page, exactly as it would for a genuine IPv4 address change (e.g., switching WLANs)
• The user can re-authenticate via the emailed link or by logging in again, exactly as documented today for IPv4

Use Case #9 Administrator restricts login access to specific IPv6 address ranges (Trusted IPs / allowed-IP list)

Roles: Administrator (Customer/Reseller/User configuration)

Preconditions:

• Customer "Nordic Fiber" has several remote support-desk staff who need self-care/reseller-portal access restricted to the company's own networks
• The company's network includes an IPv6 allocation 2001:db8:5::/48 alongside a legacy IPv4 range 203.0.113.0/24

Use Scenario #9.1 Administrator adds an IPv6 CIDR range to the allowed-IP list

• Administrator opens Customer "Nordic Fiber"'s access configuration and adds 2001:db8:5::/48 to the allowed-IP list, alongside the existing entry 203.0.113.0/24
• Administrator saves

Expected result:

• Both entries are saved and shown on the allowed-IP list
• A login attempt from an address inside 2001:db8:5::/48 (e.g., 2001:db8:5:1a2b::10) succeeds
• A login attempt from an address outside both ranges (e.g., 2001:db8:99::1) is rejected, exactly as an out-of-range IPv4 login attempt would be today

Use Scenario #9.2 Administrator enters a large number of IPv6 ranges for a customer with many sites

Preconditions:

• Customer "Nordic Fiber" has 40 branch offices, each with its own IPv6 allocation, and wants all 40 added to the allowed-IP list

Scenario:

• Administrator adds all 40 IPv6 CIDR entries (full-form addresses, e.g., 2001:0db8:0005:0001::/64 through 2001:0db8:0005:0028::/64) to the allowed-IP list in a single edit
• Administrator adds all 40 IPv6 CIDR entries (e.g., 2001:db8:5:1::/64 through 2001:db8:5:28::/64) to the allowed-IP list in a single edit
• Administrator saves

Expected result:

• All 40 entries are saved without truncation
• The system supports at least ~85 full-form IPv6 CIDR entries in this field before any length constraint is reached, comfortably covering realistic multi-site deployments
• The system supports at least as many IPv6 CIDR ranges in the allowed-IP list as IPv4 CIDR ranges are supported in the current implementation — IPv6 must not be more restrictive than IPv4 today
  • the specific limit is confirmed during HLD
• Login attempts from any of the 40 branch ranges succeed; attempts from outside all 40 are rejected

Use Case #10 ESPF (webhooks): provisioning events reach an external system hosted on IPv6

Roles: Administrator (Event handler configuration), external web application / HSS (webhook receiver)

Preconditions:

• MVNO "ArcticIoT" has an EventSender handler configured, subscribed to Account/New and Account/Service/Netaccess/QuotaExceeded events
• ArcticIoT's own web application, which receives these webhook POSTs and forwards relevant changes to their HSS, is now reachable only at an IPv6 address, https://[2001:db8:77::10]/espf-webhook

Use Scenario #10.1 Administrator points an EventSender handler at an IPv6-only external application

• Administrator opens the EventSender handler configuration and updates the target URL to https://[2001:db8:77::10]/espf-webhook
• Administrator saves
• On 2026-04-20 at 09:00:00, a new mobile account is created in PortaBilling, triggering an Account/New event

Expected result:

• ESPF successfully delivers the Account/New event as an HTTP POST to https://[2001:db8:77::10]/espf-webhook, and the event is visible as finished (not failed or endlessly queued) in Toolbox > External provisioning > Provisioning events

Use Scenario #10.2 Delivery to the IPv6-hosted webhook fails (error alternative to #10.1)

Preconditions:

• The EventSender handler is configured with target https://[2001:db8:77::10]/espf-webhook (per #10.1)
• The external application at 2001:db8:77::10 is temporarily unreachable (e.g., the IPv6 host is down)

Scenario:

• On 2026-04-21 at 10:00:00, a quota-exceeded event fires for account 8801012345; ESPF attempts delivery to the IPv6 webhook and receives a TCP connection timeout

Expected result:

• The event moves to failed (or queued for retry, per the handler's retry policy) state in Toolbox > External provisioning > Provisioning events — the same behavior as a failed delivery to an IPv4-hosted webhook
• The failure is logged with the target URL https://[2001:db8:77::10]/espf-webhook and the error reason visible to the administrator
• No other event handlers or accounts are affected

Use Scenario #10.3 Administrator reviews provisioning event history for an IPv6-hosted handler

• NOC engineer opens Toolbox > External provisioning > Search provisioning event, filters by the EventSender handler, and reviews recent event log entries

Expected result:

• event log entries for events sent to the IPv6-hosted webhook display and filter identically to entries for an IPv4-hosted one — no separate view or workaround needed to audit IPv6-targeted provisioning traffic

Use Case #11 PortaSIP SMPP connectivity to SMS vendors/aggregators over IPv6

Roles: Administrator (Vendor/Connection configuration), PortaSIP IMGate (SMPP client and server), SMS Vendor/Aggregator (SMPP peer)

Preconditions:

• PortaSIP cluster "SIP-Cluster-EU1" is IPv6-capable (per Use Case #1)
• Vendor "Lleida Networks" exists in the system
• The vendor's SMSC is now reachable only at IPv6 address 2001:db8:88::10, port 2775 — it has no IPv4 address on this interface
• A second, unrelated vendor "BulkSMS Europe" has an active SMPP connection to IPv4 address 198.51.100.50

Use Scenario #11.1 Administrator configures an outbound SMPP vendor connection with an IPv6 Gateway ID

Scenario:

• Administrator opens Infrastructure → Vendors → "Lleida Networks" → Connections → + Add
• Administrator fills in:
  • Service type: Messaging service
  • Type of connections: SMPP
  • Gateway ID: 2001:db8:88::10
  • Port: 2775
  • Service policy: "Vendor service policy for SMS" (Transport protocol = SMPP, Bind as = transceiver)
• Administrator saves the configuration

Expected result:

• Connection is saved with Gateway ID 2001:db8:88::10; no validation error is raised for a colon-containing IPv6 literal in the Gateway ID field, and the value is not silently truncated or misparsed the way a naive IPv4 validator would
• The connection appears in the vendor's connection list with status active, exactly as an IPv4-addressed SMPP connection would
• Audit log records: timestamp, actor, action "Connection created", Vendor "Lleida Networks", Gateway ID 2001:db8:88::10

Use Scenario #11.2: Administrator enters a malformed IPv6 Gateway ID (Error alternative to #11.1)

• Administrator enters 2001:db8:88:10 (only 4 of the required 8 hextet groups, with no :: compression — not a valid IPv6 address and not a valid IPv4 address) in the Gateway ID field of the SMPP connection form
• Administrator saves

Expected result:

• System displays validation error: "Invalid IP address format. Enter a valid IPv4 or IPv6 address."
• Connection is not created; Administrator remains on the form with entered values preserved
• No SMPP session attempt is made toward the malformed address

Use Scenario #11.3: PortaSIP routes an outgoing SMS through an IPv6 SMPP vendor connection

Preconditions:

• Connection to "Lleida Networks" is configured per Scenario #11.1
• Service policy selects SMPP transport and matches the destination domain pattern for Spanish numbers (%34%)
• Internal account 3465558915 (configured per the SMS Notifications handbook) sends a payment-overdue notification SMS to +34604555123

Scenario:

• On 2026-04-21 at 10:00:00, PortaBilling triggers an overdue-invoice notification; IMGate selects the "Lleida Networks" SMPP connection via LCR routing
• IMGate opens a TCP connection to [2001:db8:88::10]:2775, completes the SMPP bind (bind_transceiver), and submits a SUBMIT_SM PDU
• The vendor's SMSC returns ESME_ROK

Expected result:

• SMS is successfully submitted to the vendor; xDR for the outgoing message is created with originating account 3465558915, destination +34604555123, result failed = 0
• IMGate's connection toward [2001:db8:88::10]:2775 is logged with the IPv6 remote address, exactly as an IPv4 connection would be logged with its address
• The second vendor "BulkSMS Europe" (IPv4, 198.51.100.50) is not affected: its SMPP session remains stable and routes its own traffic independently

Use Scenario #11.4:  SMPP connection fails because Gateway ID is still IPv4 but vendor is now IPv6-only (Error alternative to #11.3)

Preconditions:

• Connection to "Lleida Networks" still has the old Gateway ID 198.51.100.10 (IPv4); the vendor's SMSC now listens only on 2001:db8:88::10
• PortaBilling selects this connection for an outgoing SMS notification

Expected result:

• IMGate fails to establish the TCP connection to 198.51.100.10:2775 (vendor no longer listens there) and logs a connection error
• The outgoing SMS notification is either rerouted via the next available connection (if one exists and LCR permits) or remains undelivered
• The failure is visible in Toolbox → Log viewer with the SMPP connection error and the vendor name, consistent with how any SMPP connection failure is surfaced today
• No xDR with failed = 0 is created for the undelivered message; a failed-attempt xDR is produced if PortaBilling's existing error-accounting behavior applies

Use Scenario #11.5: PortaSIP accepts an incoming SMPP connection from an IPv6-only mobile operator

Preconditions:

• PortaSIP cluster "SIP-Cluster-EU1" has its IPv6 Service IP 2001:db8:1::100 configured (per Use Case #1)
• Mobile operator "NordicMobile" submits incoming SMS to PortaSIP subscribers via SMPP; NordicMobile's SMSC is IPv6-only at 2001:db8:77::55 and binds to IMGate's SMPP listener
• A service policy with domain pattern matching NordicMobile's sender domain (e.g., %nordic%) is configured with Transport protocol = SMPP, and specifies inbound-AAA handling

Scenario:

• On 2026-04-22 at 14:00:00, NordicMobile's SMSC opens a TCP connection from 2001:db8:77::55 to IMGate's SMPP listener on the cluster's IPv6 VIPA ([2001:db8:1::100]:2775), and issues a bind_receiver or bind_transceiver
• NordicMobile submits a DELIVER_SM PDU for subscriber account anna.berg@nordicvoice.example
• IMGate authorizes the incoming message in PortaBilling, converts the SMPP message to SIP MESSAGE, and delivers it to the subscriber's registered UA

Expected result:

• IMGate accepts the bind from 2001:db8:77::55 without error; the SMPP session is established over IPv6
• The incoming SMS is delivered to the subscriber; if the subscriber is offline, IMGate stores the message until the next registration, exactly as it does today for IPv4-originated incoming SMS
• The inbound xDR records the source SMPP peer as 2001:db8:77::55, not silently dropped or misrecorded
• No NAT64 or IPv4 relay is required in front of IMGate's SMPP listener

Use Scenario #11.6 Dual-stack SMPP — vendor reachable at both IPv4 and IPv6 (optional)

Preconditions:

• Vendor "Lleida Networks" has two connections configured: one with Gateway ID 198.51.100.10 (IPv4, lower route cost) and one with Gateway ID 2001:db8:88::10 (IPv6, fallback), both active

Scenario:

• An outgoing SMS is routed via LCR; the IPv4 connection is preferred and selected
• On 2026-04-23 at 09:00:00, IMGate detects consecutive SMPP bind failures on the IPv4 connection and marks it unavailable; PortaBilling's LCR excludes the failed connection and falls back to the IPv6 connection
• Subsequent outgoing SMS messages route through 2001:db8:88::10

Expected result:

• LCR failover from the IPv4 to the IPv6 connection works exactly as failover between two IPv4 connections works today — address family is transparent to the routing logic
• xDRs for messages sent via the IPv6 connection record Gateway ID 2001:db8:88::10; xDRs for messages sent via the IPv4 connection record 198.51.100.10 — no cross-attribution

Wireframes

N/A — this feature is primarily an infrastructure/backend capability (Node matching, RADIUS/Diameter AVP handling, SIP header/Service-IP processing). The only UI-visible change is existing IP-address fields across the Admin Web interface (Node/Service IP configuration, Log Viewer and Active Sessions search fields) accepting and displaying IPv6 syntax; so most probably, no new panels, tabs, or pages are introduced.

Non-functional requirements

1. All external-facing interfaces — SIP signaling, RADIUS, Diameter, SMPP, and Web (self-care/admin) — shall support IPv4 and IPv6 simultaneously: a deployed system shall accept connections from IPv4-only, IPv6-only, and dual-stack (optional) external parties at the same time, on the same running instance, without requiring a mode switch, configuration toggle, or service restart. IPv4-only operation shall remain fully functional and unaffected, including the existing DNS64/NAT64 processing.
   • Verification: all scenarios in Use Cases #1–#11 that involve an IPv4-addressed Node, connection, or UA (e.g., #5.2, #2.3, #11.6) must produce identical results before and after IPv6 support is deployed.
2. IPv6 addresses are validated server-side against RFC 4291 format rules before being persisted; malformed input is rejected
3. Existing voice fraud-detection logic (including geo-IP-based checks) shall apply to IPv6 source addresses using the same code path and evaluation logic as for IPv4 source addresses — specifically, an IPv6 source address shall be resolved through the geo-IP lookup, compared against the account's last-known location, and flagged under the same threshold conditions. No IPv6-sourced session shall bypass fraud detection due to an unchecked address family.
   
4. Existing voice fraud-detection logic (including geo-IP-based checks) shall apply to IPv6 source addresses using the same code path and evaluation logic as for IPv4 source addresses — specifically, an IPv6 source address shall be resolved through the geo-IP lookup, compared against the account's last-known location, and flagged under the same threshold conditions. IPv6 geo-IP coverage is materially weaker than IPv4, meaning lookup misses will occur more frequently; the behavior on a lookup miss:
   1. whether to treat the session as indeterminate location and skip the geo-IP comparison,
   2. or to apply a fallback rule — must be defined during HLD
5. Network-level abuse protection (DoS/rate-limiting, allow-listing of trusted partner networks) shall protect IPv6 Service IP traffic to the same standard as IPv4 traffic today
6. xDR search and reports (e.g., Cost/revenue statistics) expose subscriber_ip values in IPv6 or dual-stack notation without truncation or reformatting

Peculiarities

1. A Node may be registered with one primary identifier (IPv4 or IPv6) plus optional additional identifiers of either family (Scenario #5.2), rather than requiring two entirely separate Node records for the same physical NAS.
2. For dual-stack sessions (Scenario #5.6), usage is billed once per session regardless of how many IP families carried traffic; this assumes the NAS/P-GW reports accounting octets as a single combined counter.
3. For Use Case #8, adding IPv6 support to all the existing self-care portals (including Admin WI) must not introduce re-authentication prompts that did not exist for equivalent IPv4 sessions — specifically, routine OS-level IPv6 privacy address rotation (a default behavior on Windows, macOS, iOS, and Android) must not trigger re-authentication during an active portal session. The mechanism for achieving this is deferred to HLD/LLD, where it must be determined based on how the existing IPv4 session security is currently implemented.
4. All existing on PortaConfigurator Web Interface instances that are now support IPv4 should also support IPv6
5. All existing PortaSIP/DSBC mail and messaging components shall support IPv6 in addition to IPv4 on both their faces:
   1. internal component-to-component transport: either IPv4 or IPv6 is acceptable; dual-stack is not required internally (see NFR #1)
   2. their external service borders on the cluster's VIPA/Service IPs — inbound SMTP/SMTPS (MX-published, e.g., email callback and email delivery to SIP users), IMAP/POP3 mailbox access by end-user email clients, and outbound SMTP forwarding to external mail servers. On an IPv6-only cluster (Peculiarity 7), these external borders are reachable only over IPv6 by definition.
   3. External-facing SMPP connectivity is covered by Use Case #11. Unlike the mail borders listed above, IMGate operates in both directions: as a TCP client (outbound binds to vendor/aggregator SMSCs, configured via the vendor connection's Gateway ID field) and as a TCP server (accepting inbound SMPP binds from mobile operators on the cluster's VIPA). Both directions require IPv6 socket support. MVNO "dummy" SMPP connections (Gateway ID = "RO", active = disabled) never open a real TCP connection and are therefore unaffected. The external mail borders (inbound SMTP and IMAP client access over the IPv6 VIPA) are covered by Use Scenario #1.9, and outbound SMTP delivery by Use Scenario #1.4.
6. Dual-stack flow related:
   1. Voice services (PortaSIP):
      • The address family used by an external SIP element (UA, SBC, vendor gateway) — including any switch between families on a dual-stack endpoint — is selected entirely by that element, per its own SIP stack, IP-mode preference settings, and DNS resolution/retry behavior.
      • PortaSIP guarantees only that a registration or call arriving over either family is accepted, matched to the correct account or connection, and (for registrations) bound as that account's single active registration (cross-family binding replacement applies when dual-stack voice, Use Case #2, is deployed).
      • PortaSIP does not initiate, accelerate, or guarantee endpoint fallback (it depends on the specific UA/SBC deployed); calls already established over a failing family are not expected to survive a mid-call switch.
      • Why acceptance of both families is still required: the equipment that switches families is mainstream, and the switch is not under CSP control. Dual-stack IP mode is a standard setting on major desk phones (Yealink T-series, Grandstream GXP, Snom D-series); IPv4/IPv6 dual-stack and cross-family interworking is a core function of every major SBC (Ribbon, AudioCodes, Oracle); IMS/VoLTE cores are IPv6-first by design. A firmware update, an SBC's DNS resolution choice, or an admin setting can change the arriving family at any time.
      • What is not mainstream is seamless automatic runtime fallback on path failure: endpoints typically pick a family at registration/DNS-resolution time and change it only on reboot, reconfiguration, or re-resolution.
   2. Broadband / mobile services via RADIUS/Diameter (PortaBilling):
      • Which address family (or both) a session reports is decided entirely by the NAS/BRAS/P-GW; the CSP cannot restrict what arrives.
      • Dual-stack is the default first step of real-world operator IPv6 rollouts, not an edge case: a NAS serving a dual-stack subscriber will report Framed-IP-Address and Framed-IPv6-Prefix in the same session, and a mobile core may hand a session from one family to the other mid-session (Scenarios #5.6, #6.2)
7. Outbound email delivery (voicemail/fax notifications, message forwarding) from an IPv6-only cluster's Mail Proxy to an IPv4-only external mail server is a v6→v4 case with no translation mechanism in the mail path. Scenario #1.4 deliberately tests delivery to a dual-stack receiver only. The mechanism for reaching IPv4-only receivers from an IPv6-only cluster (e.g., a dual-stack relay/smarthost, or another approach) is an SD-phase decision; until decided, CSPs on IPv6-only clusters should assume notification delivery is guaranteed only to dual-stack or IPv6-capable mail servers.
8. In DHCPv6-PD deployments, a BRAS may include Delegated-IPv6-Prefix (RFC 4818) in RADIUS Accounting-Request messages alongside Framed-IPv6-Prefix. PortaBilling shall accept such packets without session rejection; Delegated-IPv6-Prefix is stored in the session xDR when present but is not used as a session identifier or billing driver. Matching and charging continue to be based on Framed-IPv6-Prefix and account identity
   • Whether specific P-GW/SMF vendors include Delegated-IPv6-Prefix in Gy CCR messages is implementation-dependent and not governed by 3GPP standards; Diameter dictionary support for this AVP is deferred to the HLD/LLD phase.

Performance / Clustering, Geo Redundancy/ Dual-Version, Porter / Call Control API / ESPF / Monitoring

• Clustering: applicable to all existing components that can be clustered i.e. SIP, BE, Web. Should be consistent with existing IPv4 cluster approach. 
• Clustering: applicable to all existing components that can be clustered i.e. SIP, BE, Web. The IPv6 Service IP must fail over between cluster nodes and the newly active node must be reachable over IPv6 within the same time window as IPv4 failover today.
• Geo Redundancy / Monitoring: should be compatible with an IPv6
• Dual-Version / Porter: IPv6 support for Dual-Version migration between two releases that both include native IPv6 support — for example, if IPv6 is introduced in MR150, then an MR150 → MR155 DV migration must sustain IPv6 operation throughout
• PortaBilling API, PortaSIP API, ESPF API, and Call Control API: shall each be verified for IPv4/IPv6 dual-stack compatibility — specifically, that every IP-address-typed request/response parameter, connection string, and callback/webhook URL construction accepts and correctly round-trips IPv6 values. This is deferred to HLD/LLD phases.
• Performance:
  • IPv6-sourced RADIUS Access-Request matching against a Node completes within the same 50 ms median processing budget as IPv4-sourced requests (no measurable regression)
  • Diameter Gy CCR processing time for IPv6-attributed sessions stays within the existing 100 ms median CCA response budget
  • IPv6 processing across all PortaSwitch/PortaBilling components must not regress existing IPv4 performance. Following delivery, QA executes full performance testing across all affected components under IPv6 load; results are reviewed with PO and engineering to determine whether performance is acceptable for release or further optimization is required.

Out-of-scope items

1. Any change to PortaSIP's existing DNS64/NAT64 call-processing logic
   • the existing logic already distinguishes 'synthetic IPv6' as a concept — whether the NAT64 prefix can serve as the native-vs-NAT64 discriminator is an SD question.
2. Existing auto-provisioning profiles of IP phones
3. Old-style ESPF handlers (including mobile cores we integrated in the past) though excluding those handles that are internally used e.g. like SIPForwarder in a DV setup
4. Existing PortaOne Workflows integrations
5. Existing Add-on Mart modules
6. Existing custom xDR Mediator converters (modules for custom data transformation logic)
7. Existing custom reports e.g. like IFRS
8. IPv4-over-IPv6 transition mechanisms (DS-Lite, MAP-T/MAP-E, lw4o6, 464XLAT) — specifically, provisioning of their mechanism-specific RADIUS/Diameter attributes (e.g., RFC 6519, RFC 8658) for the Internet access service — are out of scope