This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The OpenGGSN project".

The branch, laforge/ipv6 has been updated
  discards  69ba8a611a6e4bf5e92cb84d56f147732e9b2d89 (commit)
  discards  c2897ac13f6b289e74c001a5cad6b068bf2ca1df (commit)
  discards  84c2d0f286cf74c8dd42133241df5ca51dfbb0b8 (commit)
  discards  949e50e02bb1af911dca820f21a11232f615e106 (commit)
  discards  714a41bf66932bb6b383cd4573d1eff51aaf50dd (commit)
       via  86f42e4d9d17f4134018a556070d801adf64d974 (commit)
       via  8b74b473e235cc409a4a443ba82ffd20df452b13 (commit)
       via  95340e164e12a89a8e15750cd17503a89baaca9a (commit)
       via  4f2c0e3e7627ffe0762d96f3289f71632ea9b32f (commit)
       via  d4d6e09fd29e23e28960959ca488e1481339571e (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (69ba8a611a6e4bf5e92cb84d56f147732e9b2d89)
            \
             N -- N -- N (86f42e4d9d17f4134018a556070d801adf64d974)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://cgit.osmocom.org/openggsn/commit/?id=86f42e4d9d17f4134018a556070d801adf64d974

commit 86f42e4d9d17f4134018a556070d801adf64d974
Author: Harald Welte <lafo...@gnumonks.org>
Date:   Thu Aug 3 00:47:03 2017 +0200

    Support setting TUN device IPv6 address + prefix
    
    As we can now have PDP contexts with IPv6 user IP payload,
    it is useful to extend the TUN related code to be able to
    configure the tun device IPv6 address + prefix length
    
    Change-Id: I899d21e52d02e0b8384af29ddd489ff19c8f2cf6

http://cgit.osmocom.org/openggsn/commit/?id=8b74b473e235cc409a4a443ba82ffd20df452b13

commit 8b74b473e235cc409a4a443ba82ffd20df452b13
Author: Harald Welte <lafo...@gnumonks.org>
Date:   Wed Aug 9 21:58:12 2017 +0200

    IPv6: in46_addr: OSMO_ASSERT() in case of unsupported calls
    
    There's a bit of trickery with the ip_pool and it's "lengty=8" IPv6
    prefix handling, let's make sure we don't accidentially call any
    support functions with addresses of wrong length.
    
    Change-Id: I444c190bdcd18780344e1f0dad4faf3bcf9da5a5

http://cgit.osmocom.org/openggsn/commit/?id=95340e164e12a89a8e15750cd17503a89baaca9a

commit 95340e164e12a89a8e15750cd17503a89baaca9a
Author: Harald Welte <lafo...@gnumonks.org>
Date:   Wed Aug 9 20:28:52 2017 +0200

    IPv6: Support PCO for IPv6 DNS addresses
    
    In IPv6, DNS server information is not passed along as IPCP6 like
    in IPv5 with IPCP.  The reason is that IPCP6 (for PPP) doesn't
    support passing DNS server information.  Rather, the relevant RFCs
    indicate DHCPv6 should be used even over point-to-point links.
    
    3GPP decided to avoid DHCPv6 dependency for stateless autoconfiguration
    (the only mandatory IPv6 configuration mechanism) and added some new
    non-PPP-style PCO information elements ("containers") which can among
    other things inform a MS about IPV6 DNS servers.
    
    That same mechanism can also be used to inform the MS about IPv4 DNS
    servers, so for IPv4 there are now two competing mechanisms: IPCP and
    the new "native" PCO container.  With this patch, we support both
    for IPv4.
    
    Change-Id: I21499afd61def8c925f7838bde76f34d28214b56

http://cgit.osmocom.org/openggsn/commit/?id=4f2c0e3e7627ffe0762d96f3289f71632ea9b32f

commit 4f2c0e3e7627ffe0762d96f3289f71632ea9b32f
Author: Harald Welte <lafo...@gnumonks.org>
Date:   Tue Aug 8 23:27:22 2017 +0200

    IPv6: Implement IPv6 prefix assignment via ICMPv6 router advertisement
    
    The 3GPP specs are quite strange when it comes to how an IPv6 address
    or rather prefix is assigned to an IPv6 PDP context.  The designated
    method for allocating the IPv6 address via the PDP EUA (End User
    Address) Information Element in the GTP signalling plane is *not*
    used to allocate the address/prefix.  Instead, the EUA is used to
    allocate an "interface identifier" to the MS, which it the uses
    to derive its link-local source address to send a router solicitation.
    
    The GGSN subsequently answers witha router advertisement, advertising
    a single/64 prefix, whihcthe MS then uses to generate it's real IPv6
    source address for subsequent communication.
    
    Change-Id: Icddf7d30e01d76a4784bcef5787b36f52f703a9f

http://cgit.osmocom.org/openggsn/commit/?id=d4d6e09fd29e23e28960959ca488e1481339571e

commit d4d6e09fd29e23e28960959ca488e1481339571e
Author: Harald Welte <lafo...@gnumonks.org>
Date:   Tue Aug 8 18:10:43 2017 +0200

    ippool: Extend pool to work with /64 prefixes
    
    In IPv6 GPRS, we actually don't want to allocate an individual v6
    address (like in IPv4), but we want to allocate a prefix.  The
    standard prefix lengh is 8 bytes, i.e. a /64 prefix.  This patch
    extends the pool to be able to work with such v6 prefixes.
    
    Change-Id: I0cf700b6baf195a2e5fbea000531f801acaaa443

-----------------------------------------------------------------------

Summary of changes:


hooks/post-receive
-- 
The OpenGGSN project

Reply via email to